1.1 CONCEPTOS DE LOS PATRONES DE SOFTWARE.

¿Qué es un patrón?

 Según  Christopher Alexander “cada patrón  describe  un  describe un problema   que  ocurre  una y otra vez  en nuestro entorno, así  como la solución a ese problema de tal modo que se pueda aplicar  esta solución un millón de veces , sin hacer lo mismo dos veces “ a la vez que propone una solución idónea aplicable a dicho problema.

4 elementos esenciales:

1.           Un nombre de patrón  permite  describir, en una o dos palabras, un problema de diseño  junto con sus soluciones y consecuencias.
2.            Problema describe cuando aplicar el patrón. Explica el problema y su contexto.
3.            La solución describe los elementos que construyen  en el diseño, sus relaciones, responsabilidades y colaboraciones.
4.          Las consecuencias explican los resultados de aplicar el patrón, sus costes y beneficios.

 Los patrones de diseño de  los cuales se clasifican como se muestra a continuación:

·         Patrones Creacionales: Inicialización y configuración de objetos.

Fábrica Abstracta ( Abstract Factory )

Método de Fabricación ( Factory Method )

Prototipado ( Prototype )

Singleton

MVC ( Model View Controler )

·         Patrones Estructurales: Separan la interfaz de la implementación. Se ocupan de cómo las clases y objetos se agrupan, para formar estructuras más grandes.

Adaptador (Adapter)

Puente (Bridge)

Objeto Compuesto (Composite)

Envoltorio (Decorator

Fachada (Facade) Peso Ligero (Flyweight)

Apoderado (Proxy)

·        

Patrones de Comportamiento: Más que describir objetos o clases, describen la comunicación entre ellos.

Objetivos  de los patrones.

Los patrones de diseño pretenden:

•       Proporcionar catálogos de elementos reusables en el diseño de sistemas software.
•       Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.
•       Formalizar un vocabulario común entre diseñadores.
•      Estandarizar el modo en que se realiza el diseño.
•      Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente.

Asimismo, no pretenden:

•       Imponer ciertas alternativas de diseño frente a otras.
•      Eliminar la creatividad inherente al proceso de diseño.

1.2 Tipos 1.2.1 Business Delegate

El Business Delegate actúa como una abstracción de negocio del lado del cliente; proporciona una abstracción para, y por lo tanto oculta, la implementación de los servicios del negocio. Utilizando Business Delegate se reduce el acoplamiento entre los clientes de la capa de presentación y los servicios de negocio del sistema.

Estructura
La siguiente figura muestra el diagrama de clases que representa al patrón Business Delegate. El cliente solicita al BusinessDelegate que le proporcione acceso al servicio de negocio subyacente. El BusinessDelegate utiliza un LookupService para localizar el componenteBusinessService requerido.

Participantes y Responsabilidades

La siguiente figura muestra el diagrama de secuencia que ilustra las interacciones típicas para este patrón:

El BusinessDelegate utiliza un LookupService para localizar el servicio de negocio. El servicio de negocio se utiliza para invocar a los métodos de negocio por cuenta del cliente. 

El métodoGet_ID muestra que el BusinessDelegate puede obtener una versión String del handle(como un objeto EJBHandle) para el servicio de negocio y devolverlo al cliente como unString. 

El cliente puede utilizar la versión String del handle más tarde para reconectar con el servicio de negocio que estaba utilizando cuando obtuvo el handle. 

Esta técnica evitará nuevas búsquedas, ya que el handle es capáz de reconectar con su ejemplar del servicio de negocio. Se debería observar que los objetos handle los implementa el contenedor y podrían no ser portables entre contenedores de diferentes vendedores.


El diagrama de secuencia de la obtención de un BusinessService (como un bean de sesión o de entidad) utilizando este handle.

El rol de BusinessDelegate es proporcionar control y protección para el servicio de negocio.BusinessDelegate puede exponer dos tipos de constructores al cliente. 

Un tipo de petición ejemplariza el BusinessDelegate sin una ID, mientras que el otro lo inicializa con un ID, donde ID es una versión String de la referencia al objeto remoto como un EJBHome o unEJBObject.

Ø ElBusinessDelegate pide que el Service Factory localice, cree o elimine un BusinessService, como un bean enterprise.

Ø Cuando se inicializa con un ID, el BusinessDelegate usa el ID para reconectar con elBusinessService. Así, el BusinessDelegate aisla al cliente de los detalles de la implementación del BusinessService de nombrado y búsqueda.

Ø Además, el cliente de la capa de presentación nunca hace llamadas remotas directas sobre un BusinessSession; en su lugar, el cliente utiliza el BusinessDelegate.

El Business Delegate expone un interface que proporciona a los clientes acceso a los métodos subyacentes del API de servicios de negocio. En esta estrategia, un Business Delegate proporciona la función de proxy para pasar los métodos del cliente al bean de sesión que encapsula. 

Adicionalmente el Business Delegate podría hacer un caché con los datos necesarios, incluyendo las referencias remotas de los objetos home o remote del bean de sesión para mejorar el rendimiento reduciendo el número de búsquedas.

Se utiliza para separar capa de presentación y la capa de negocio. Se utilizan básicamente para reducir la comunicación o la funcionalidad de búsqueda de código remoto capa de negocios en la presentación de código de nivel. 

Ø Client - Presentación código puede ser JSP, servlet o UI código java.

Ø Delegado de negocios - Una única clase de punto de entrada para las entidades cliente para proporcionar acceso a los métodos de servicios empresariales.

Ø Servicio de Búsqueda - objeto de servicio de búsqueda se encarga de obtener la ejecución de negocios relativa y proporcionar acceso a objetos de negocio a negocio objeto delegado.

Ø Servicios de Negocio - Interfaz de Servicios de Negocio. Las clases concretas implementa este servicio para proporcionar lógica de negocio real aplicación de negocios.

1.2.2 Composite Entity

¿QUE ES?

Patrón Composite Entity es utilizado en EJB mecanismo de persistencia. Una entidad compuesta es una entidad bean EJB que representa un gráfico de objetos. Cuando una entidad compuesta se actualiza, frijoles objetos dependientes internamente se actualizan automáticamente, ya que está gestionado por EJB Entity Bean.

· Los beans de entidad son mejores para implementar objetos genéricos debido a la alta sobrecarga asociada con todo bean de entidad. Todo bean de entidad se implementa utilizando muchos objetos, como el objeto home, el objetoremote, la implementación del bean, y la clave primaria, y todos son controlados por los servicios del contenedor.


El diagrama de secuencia muestra las interacciones para este patrón:

Participantes y Responsabilidades

CompositeEntity es un bean de entidad genérico. Podría ser un objeto genérico, o podría contener una referencia a un objeto genérico.

Coarse-Grained Object

Un objeto genérico es un objeto que tiene su propio ciclo de vida y que maneja sus propias relaciones con otros objetos. Un objeto genérico puede ser un objeto Java contenido en elCompositeEntity. O, el propio Composite Entity puede ser un objeto genérico que contiene objetos dependientes.
DependentObject1, DependentObject2, y DependentObject3Un objeto dependiente es un objeto que depende de un objeto genérico el cual gobierna el ciclo de vida del objeto dependiente. Un objeto dependiente puede contener otros objetos dependientes; así podría existir un árbol de objetos dentro del Composite Entity.
Estrategias


Esta sección explica las diferentes estrategias para implementar el patrón Composite Entity. Las estrategias consideran posibles alternativas y opciones para objetos persistentes (genéricos y dependientes), y la utilización deTransfer Objects.
El Composite Entity Contiene Objetos Genéricos


En esta estrategia, el Composite Entity almacena o contiene el objeto genérico. Este objeto genérico continúa teniendo relaciones con sus objetos dependientes. La sección Estructura describe esta estrategia principal.
El Composite Entity Implementa el Objeto Genérico


En esta estrategia, el propio Composite Entity es el objeto genérico y tiene atributos y métodos de objeto genérico. Los objetos dependientes son atributos del Composite Entity. Como el Composite Entity es el objeto genérico, el bean de entidad expresa y maneja todas las relaciones entre el objeto genérico y los objetos dependientes. La siguiente figura muestra el diagrama de clases de esta estrategia:

1.2.3 Composite View

El patrón Composite sirve para construir objetos complejos a partir de otros más simples y similares entre sí, gracias a la composición recursiva y a una estructura en forma de árbol.

Ayuda al proceso de integración de varias subvistas en una página.

Propone componer una vista de numerosas piezas atómicas

Combina vistas simples en una visión más compleja y sin manipular el contenido o el diseño.

Esto simplifica el tratamiento de los objetos creados, ya que al poseer todos ellos una interfaz común, se tratan todos de la misma manera.

Estructura

Se muestra el diagrama de clases que representa el patrón Composite View.

Participantes y Responsabilidades

Se muestra el diagrama de secuencia para el patrón Composite View.

Ø CompositeView: Una vista compuesta es una vista a la que se le han agregado varias subvistas.

Ø ViewManager: El manejador de vista se ocupa de la inclusión de porciones de fragmentos de plantilla en la vista compuesta.

Ø HeaderView: Es una subvista incluida dentro de la principal.

Ø FooterView: Es una subvista incluida dentro de la principal.

Implementación

Un Composite View se puede implementar siguiendo la estrategia JSP page View o bien la estrategia Servlet View. [Alur]


El control de la vista se puede implementar de diferentes formas: utilizando etiquetas jsp estándar, como <jsp:include>, utilizando componentes JavaBeans, y también mediante etiquetas personalizadas (JSP 1.1+).

Consecuencias

 Mejora la Modularidad y la Reutilización.

El modelo promueve el diseño modular. Es posible volver a usar porciones atómicas de una plantilla, como una tabla de cotizaciones de bolsa, en numerosos puntos de vista y para decorar estas porciones reutilizadas con información diferente. Este patrón permite la mesa para ser trasladado a su propio módulo y simplemente incluida en caso necesario. Este tipo de diseño y composición dinámica reduce la duplicación, fomenta la reutilización y mejora el mantenimiento.

· Mejora la Flexibilidad

Una implementación sofisticada puede incluir condicionalmente ver fragmentos de plantilla en base a las decisiones de ejecución, tales como la función de usuario o la política de seguridad.

· Mejora la mantenibilidad y Manejabilidad

Es mucho más eficiente para administrar los cambios en porciones de una plantilla cuando la plantilla no está codificada directamente en la vista de marcado. Cuando se mantiene separada de la vista, es posible modificar porciones modulares de contenido de la plantilla independiente de la disposición de la plantilla. Además, estos cambios están disponibles para el cliente inmediatamente, dependiendo de la estrategia de implementación. Las modificaciones del diseño de una página se controlan más fácilmente, así, ya que los cambios están centralizados.

· Reduce Manejabilidad

Agregación de piezas atómicas de la pantalla en conjunto para crear una única vista introduce la posibilidad de errores en la pantalla, ya que subvistas son fragmentos de página. Esta es una limitación que puede convertirse en un problema de manejabilidad. Por ejemplo, si una página de la página JSP está generando una página HTML usando una página principal que incluye tres subvistas, y las subvistas cada incluyen la etiqueta HTML de apertura y cierre (es decir, <HTML> y </ HTML> ), entonces el compuestas la página no será válida. Por lo tanto, es importante cuando se utiliza este patrón a ser consciente de que subvistas no deben ser vistas completas. Uso de Tag debe tenerse en cuenta muy estricta con el fin de crear vistas compuestas válidos, y esto puede convertirse en un problema de gestión.· Impacto en el rendimiento

Generando una pantalla que incluye numerosas subvistas puede disminuir el rendimiento.Duración de la inclusión subvistas resultará en un retraso cada vez que la página se sirve al cliente. En un entorno con estrictos acuerdos de nivel de servicio que los tiempos de respuesta de mandatos específicos, tales ralentizaciones de rendimiento, pero en general muy mínimas, no pueden ser aceptables. Una alternativa es mover la inclusión subvista al tiempo de traducción, aunque esto limita la vista secundaria a los cambios cuando la página se retraducido.

1.2.4 Data Access Object (DAO)

Es un componente de software que suministra una interfaz común entre la aplicación y uno o más dispositivos de almacenamiento de datos, tales como una Base de datos o un archivo. El término se aplica frecuentemente al Patrón de diseño Object.

Ø Generalmente esta API consiste en métodos CRUD (Create, Read, Update, y Delete). Entonces por ejemplo cuando la capa de lógica de negocio necesite guardar un dato en la base de datos va a llamar a un método créate().

Ventajas

Los Objetos de Acceso a Datos son un Patrón de los subordinados de Diseño Core J2EE y considerados una buena práctica. La ventaja de usar objetos de acceso a datos es que cualquier objeto de negocio (aquel que contiene detalles específicos de operación o aplicación) no requiere conocimiento directo del destino final de la información que manipula.

Los Objetos de Acceso a Datos pueden usarse en Java para aislar a una aplicación de la tecnología de persistencia Java subyacente (API de Persistencia Java), la cual podría ser JDBC, JDO, Enterprise JavaBeans, TopLink, Hibernate, iBATIS, o cualquier otra tecnología de persistencia. Usando Objetos de Acceso de Datos significa que la tecnología subyacente puede ser actualizada o cambiada sin cambiar otras partes de la aplicación.

Desventajas

La flexibilidad tiene un precio. Cuando se añaden DAOs a una aplicación, la complejidad adicional de usar otra capa de persistencia incrementa la cantidad de código ejecutado durante tiempo de ejecución. La configuración de las capas de persistencia requiere en la mayoría de los casos mucho trabajo.


Estructura DAO 

Ø BusinessObject: Es el objeto que quiere acceder a la fuente de datos para poder almacenar o consultar datos.

Ø DataAccessObject: Abstrae al BusinessObject de los detalles del acceso a la fuente de datos.

Ø DataSource: Representa la implementacion de la fuente de datos en sí.

Ø TransferObject: Es un objeto intermedio entre el BussinessObject y el DataAccessObject.

1.2.5 Fast Lane Reader

Este patrón propone un mecanismo para obtener grandes cantidades de información utilizando un acceso directo sobre la base de datos.

• Implementación

Ø casos de uso que corresponden a búsquedas que devuelven una colección de objetos

Ø cuando se tienen casos de uso que corresponden a búsquedas múltiples y la eficiencia es un factor importante.

Estructura
Participantes

Ø Business Delegate

Delega las operaciones de búsqueda múltiple en un Session Facade( que usa un DAO) o directamente en un DAO

Ø SessionFacade


Un Session Bean que implementa las operaciones de búsqueda múltiple delegando en un DAO

Ø DAO

Proporciona las operaciones de búsqueda accediendo directamente a la BD

Colaboraciones

Un Business Delegate implementa las operaciones de búsqueda múltiple delegando en un Session Facade(que usa un DAO) o Directamente en un DAO

1.2.6 Front Controller

Es un patrón de diseño que se basa en usar un controlador como punto inicial para la gestión de las peticiones. El controlador gestiona estas peticiones, y realiza algunas funciones como: comprobación de restricciones de seguridad, manejo de errores, mapear y delegación de las peticiones a otros           componentes de la aplicación que se encargarán de generar la vista adecuada para el usuario.

El patrón Front Controller podría dividir la funcionalidad en 2 diferentes objetos: el Front Controller y el Dispatcher. En ese caso, El Front Controller acepta todos los requerimientos de un cliente y realiza la autenticación, y el Dispatcher direcciona los requerimientos a manejadores apropiada.

Ventajas

Ø Tenemos centralizado en un único punto la gestión de las peticiones.

Ø Aumentamos la reusabilidad de código.

Ø Mejoramos la gestión de la seguridad.

Desventajas

La velocidad de respuesta disminuye al tener que ser procesadas las peticiones primero por el controlador

Diagrama de la secuencia del patrón Front Controller.

Ø  Controller: Es el punto de contacto inicial para manejar todas las peticiones en el sistema. El controlador podría delegar a un helper para completar la autentificación y la autorización de un usuario o para iniciar la recuperación de un contacto.

Ø  Dispatcher: Es el responsable del manejo de la vista y de la navegación, controlando la elección de la siguiente vista que se le presentará al usuario, y proporcionando el mecanismo para dirigir el control a ese recurso.

Ø  Helper: es el responsable de ayudar a la vista o al controlador a completar su procesamiento. Así, los helpers tienen muchas responsabilidades, incluyendo la recopilación de los datos requeridos por la vista y el almacenamiento en el modelo intermedio, en cuyo caso algunas veces nos podemos referir al helper como un bean de valor. Además, los helpers pueden adaptar este modelo de datos para usarlo en la vista.

Ø  View: la representa y muestra información al cliente. La vista recupera información desde el modelo. Los helpers soportan las diferentes vistas encapsulando y adaptanto el modelo de datos subyacente para usarlo en el display.