Arquitectura de Software

  Modelos MVC El patrón MVC es una arquitectura de software que organiza una aplicación en tres componentes clave: Modelo, Vista y Controlador. ·         Modelo (Model): Representa la lógica del negocio y los datos subyacentes de la aplicación.   ·         Vista (View): Encargada de presentar la información al usuario y recibir sus interacciones.   ·         Controlador (Controller): Gestiona las interacciones del usuario y actualiza tanto el Modelo como la Vista según sea necesario. Este patrón facilita la separación de preocupaciones en una aplicación, simplificando el mantenimiento y la escalabilidad. Cada componente tiene funciones específicas, permitiendo la reutilización eficiente del código.   DAO El patrón DAO introduce una capa de abstracción entre la lógica del negocio y el acceso a los datos mediante objetos especializados (DAOs). Estos objetos encapsulan las operaciones CRUD (Crear, Leer, Actualizar, Eliminar) relacionadas con la manipulación de datos.

Adapter También llamado:  Adaptador,  Envoltorio,  Wrapper  Propósito Adapter  es un patrón de diseño estructural que permite la colaboración entre objetos con interfaces incompatibles.  Problema Imagina que estás creando una aplicación de monitoreo del mercado de valores. La aplicación descarga la información de bolsa desde varias fuentes en formato XML para presentarla al usuario con bonitos gráficos y diagramas. En cierto momento, decides mejorar la aplicación integrando una inteligente biblioteca de análisis de una tercera persona. Pero hay una trampa: la biblioteca de análisis solo funciona con datos en formato JSON. No puedes utilizar la biblioteca de análisis “tal cual” porque ésta espera los datos en un formato que es incompatible con tu aplicación. Podrías cambiar la biblioteca para que funcione con XML. Sin embargo, esto podría descomponer parte del código existente que depende de la biblioteca. Y, lo que es peor, podrías no tener siquiera acceso al código fuente de la biblio

Prototype  es un patrón de diseño creacional que nos permite copiar objetos existentes sin que el código dependa de sus clases.  Problema Digamos que tienes un objeto y quieres crear una copia exacta de él. ¿Cómo lo harías? En primer lugar, debes crear un nuevo objeto de la misma clase. Después debes recorrer todos los campos del objeto original y copiar sus valores en el nuevo objeto. ¡Bien! Pero hay una trampa. No todos los objetos se pueden copiar de este modo, porque algunos de los campos del objeto pueden ser privados e invisibles desde fuera del propio objeto. No siempre  es posible copiar un objeto “desde fuera”. Hay otro problema con el enfoque directo. Dado que debes conocer la clase del objeto para crear un duplicado, el código se vuelve dependiente de esa clase. Si esta dependencia adicional no te da miedo, todavía hay otra trampa. En ocasiones tan solo conocemos la interfaz que sigue el objeto, pero no su clase concreta, cuando, por ejemplo, un parámetro de un método acepta

  Builder También llamado:  Constructor  Propósito Builder  es un patrón de diseño creacional que nos permite construir objetos complejos paso a paso. El patrón nos permite producir distintos tipos y representaciones de un objeto empleando el mismo código de construcción.  Problema Imagina un objeto complejo que requiere una inicialización laboriosa, paso a paso, de muchos campos y objetos anidados. Normalmente, este código de inicialización está sepultado dentro de un monstruoso constructor con una gran cantidad de parámetros. O, peor aún: disperso por todo el código cliente. Crear una subclase por cada configuración posible de un objeto puede complicar demasiado el programa. Por ejemplo, pensemos en cómo crear un objeto  Casa . Para construir una casa sencilla, debemos construir cuatro paredes y un piso, así como instalar una puerta, colocar un par de ventanas y ponerle un tejado. Pero ¿qué pasa si quieres una casa más grande y luminosa, con un jardín y otros extras (como sistema de

Factory Method También llamado:  Método fábrica,  Constructor virtual  Propósito Factory Method  es un patrón de diseño creacional que proporciona una interfaz para crear objetos en una superclase, mientras permite a las subclases alterar el tipo de objetos que se crearán.  Problema Imagina que estás creando una aplicación de gestión logística. La primera versión de tu aplicación sólo es capaz de manejar el transporte en camión, por lo que la mayor parte de tu código se encuentra dentro de la clase  Camión . Al cabo de un tiempo, tu aplicación se vuelve bastante popular. Cada día recibes decenas de peticiones de empresas de transporte marítimo para que incorpores la logística por mar a la aplicación. Añadir una nueva clase al programa no es tan sencillo si el resto del código ya está acoplado a clases existentes. Estupendo, ¿verdad? Pero, ¿qué pasa con el código? En este momento, la mayor parte de tu código está acoplado a la clase  Camión . Para añadir barcos a la aplicación habría qu