INSTITUTO TECNOLÓGICO
DE OAXACA
PARADIGMAS DE
SOFTWARE ORIENTADOS A PATRONES DE DISEÑO
Y COMPONENTES
UNIDAD 1
PATRONES DE DISEÑO
CATEDRÁTICO:
LIC. JAIME R. LAGUNAS
ALUMNA:
NICOLÁS MENEZ REYNA SONIA
CARRERA:
LICENCIATURA EN INFORMÁTICA
1.1 CONCEPTO DE LOS PATRONES DE SOFTWARE.
1.2 TIPOS
1.2.1 BUSINESS DELEGATE
1.2.2 COMPOSITE ENTITY
1.2.3 COMPOSITE VIEW
1.2.4 DATA ACCESS OBJECT (DAO)
1.2.5 FAST LANE READER
1.2.6 FRONT CONTROLLER
1.2.7 INTERCEPTING FILTER
1.2.8 MODEL-VIEW-CONTROLLER
1.2.9 SERVICE LOCATOR
1.2.10 SESSION FACADE
1.2.11 TRANSFER OBJECT
1.2.12 VALUE LIST HANDLER
1.2.13 VIEW HELPER
1.2.14 FÁBRICA ABSTRACTA (ABSTRACT FACTORY)
1.2.15 ADAPTADOR O ENVOLTORIO (ADAPTER O
WRAPPER)
1.2.16 DECORADOR (DECORATOR)
1.2.17 COMPOSICIÓN
(COMPOSITE)
1.2.18 ITERADOR (ITERATOR)
1.2.19 ESTRATEGIA (STRATEGY)
1.2.20 COMANDO (COMMAND)
1.2.21 OBSERVADOR (OBSERVER)
1.1 CONCEPTO
DE LOS PATRONES DE SOFTWARE.
Concepto de patrón de
diseño.
Según Christopher Alexander:
“Cada patrón de diseño 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 una y otra vez, sin repetir cada
vez lo mismo”.
CLASIFICACIÓN
DE LOS PATRONES DE DISEÑO:
1.2.1 BUSINESS DELEGATE
El rol de Business Delegate:
·
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 en la capa de negocios en la presentación de a
nivel de código.
·
Es proporcionar control y protección para el servicio de negocio.
·
Expone un interface que proporciona a los clientes
acceso a los métodos subyacentes del API de servicios de negocio.
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 del bean de sesión para
mejorar el rendimiento reduciendo el número de búsquedas.
Funcionamiento
El BusinessDelegate 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 el BusinessService.
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.
PARTICIPANTES
ü Cliente
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
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, los objetos dependientes internamente se
actualizan automáticamente, ya que está gestionado por EJB Entity Bean.
Estructura
PARTICIPANTES
Entidad Compuesta:
Es bean es
la entidad principal puede ser de CoarsegrainedObjeto
o puede contener un objeto de CoarsegrainedObjeto para ser utilizado
para el propósito de persistencia.
Objeto:
Este CoarsegrainedObjeto
objeto contiene objetos dependientes. Tiene su propio ciclo de vida y
también gestiona el ciclo de vida de los objetos dependientes.
Objeto Dependiente
(DependentObject)
Los objetos dependientes es un objeto que
depende de objeto genérico de su ciclo de vida persistencia.
Estrategias
Estrategias representa cómo implementar un
Composite Entity.
Ejemplo
En una jerarquía de componentes
de dibujo puede ser importante que todos los elementos que se puedan dibujar
compartan cierta interfaz, pero además también es importante que unos elementos
puedan formar parte de otros(los objetos línea forman parte del objeto
cuadrado).
Explicación:
La
clase dibujo define una agregación de objetos gráfico. Dibujo
implementa dibujar para que llame al Dibujar de sus hijos, y añade operaciones
relacionadas con los hijos. Como la interfaz de Dibujo se ajusta a la
interfaz de gráfico, los objetos dibujo pueden componer recursivamente
otros Dibujos.
1.2.3
COMPOSITE VIEW
PROPÓSITOS
ü 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.
ESTRUCTURA
DIAGRAMA DE SECUENCIA COMPOSITE
VIEW
PARTICIPANTES
ü 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.
El control de la vista se
puede implementar de diferentes formas:
ü Utilizando etiquetas jsp estándar, como
<jsp:include>,
ü Utilizando componentes JavaBeans,
ü Mediante etiquetas personalizadas (JSP 1.1+).
VENTAJAS
ü Se reduce la duplicación de código, ya que puede
crear encabezados, pies de página comunes y otros componentes.
ü Las vistas se pueden cambiar en base a la
autorización de acceso.
APLICABILIDAD
Use el patrón cuando:
ü Se tiene componentes de vista comunes.
ü Se ven cambios en los componentes sobre la base de la autorización.
1.2.4 DATA ACCESS OBJECT
(DAO)
DAO Es un patrón de diseño
utilizado para crear una capa de persistencia
Funcionamiento:
Encapsula el acceso a la base
de datos. Por lo que cuando la capa lógica de negocio necesite interactuar con
la base de datos, va a hacerlo a través de la API que le ofrece DAO.
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().
Consiste básicamente en una clase que es la que interactúa con la base de datos. Los métodos de esta clase dependen de la aplicación y de lo que queramos hacer.
PARTICIPANTES
ü 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
PROPÓSITO
Este
patrón propone un mecanismo para obtener grandes cantidades de información
utilizando un acceso directo sobre la base de datos.
APLICABILIDAD
Este patrón se usa aplica
en:
ü 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
1.2.6
FRONT
CONTROLLER
PROPÓSITO
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.
FUNCIONALIDAD
El patrón Front Controller
podría dividir la funcionalidad en 2 diferentes objetos:
ü Front
Controller acepta todos los
requerimientos de un cliente y realiza la autenticación
ü 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
PARTICIPANTES
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.
EJEMPLO
En esta primera imagen como podemos observar es que
para que pueda acceder a realizar alguna de estas actividades tiene que realizar por separada cada actividad y esto
hace que muchas de las aplicaciones sean más tardadas.
En la siguiente figura se muestra cómo se puede unir
a todos las actividades mediante el patrón
1.2.7
INTERCEPTING
FILTER
FUNCIONALIDAD
El mecanismo de manejo de peticiones de la capa de
presentación recibe diferentes tipos de
peticiones, cada uno de los cuales requiere varios tipos de procesamiento.
Se requiere un pre-procesamiento y un
post-procesamiento de unas peticiones o respuestas de un cliente Web.
Cuando una petición entra a una aplicación Web,
normalmente debe pasar varios test de entrada antes del estado de procesamiento
principal.
Por ejemplo:
¿Se ha autentificado el cliente?
¿Tiene el cliente una sesión válida?
Algunos de estos chequeos son tests, que resultan en
una respuesta de si o no que determina si continuará el procesamiento.
Los filtros interceptan las peticiones entrantes y
las respuestas salientes, permitiendo un pre y post-procesamiento.
Se puede decorar el procesamiento principal con una
variedad de servicios comunes, como la seguridad, el login, el depurado, etc.
Estos filtros son componentes independientes del
código de la aplicación principal, y pueden añadirse o eliminarse de forma
declarativa.
ESTRUCTURA
DIAGRAMA DE SECUENCIAS
PARTICIPANTES
ü FilterManager: El FilterManager maneja el procesamiento
de filtros. Crea el FilterChain con los filtros apropiados, en el
orden correcto e inicia el procesamiento.
ü FilterChain:
El FilterChain es una coleccion ordenada de filtros independientes.
ü FilterOne, FilterTwo, FilterThree:
Estos son los filtros individuales que son mapeados a un objetivo.
El FilterChain coordina su procesamiento.
ü Target: El Target es el
recurso que el cliente ha solicitado.
1.2.8
MODEL-VIEW-CONTROLLER
PROPÓSITO
ü Separar el código de una aplicación.
ü Aislar los cambios de la interfaz gráfica de
usuario y evitar que estos cambios impliquen cambiar la lógica de dominio de la
aplicación.
ü Reducir la distancia humano-máquina y facilitar
los cambios de la interfaz de usuario.
DESCRIPCIÓN
MVC son las siglas de Model View Controller, es
decir, modelo vista controlador.
• Es una aplicación web basada en este patrón separa su código en tres partes diferenciadas:
El
controlador, El modelo y La vista, MVC es un patrón de diseño que fue
inicialmente utilizado para construir interfaces de usuario en Smalltalk80.
• MVC es un patrón aplicado a la arquitectura de software que tiene como objetivo fundamental, separar el código de una aplicación.
MODELO-VISTA-CONTROLADOR
El patrón MVC puede estar integrado por:
• Un modelo
• Varias vistas
• Varios controladores
Las vistas y los controladores suelen estar muy
relacionados
• Los controladores tratan los eventos que se producen en la interfaz
gráfica (vista)
DIAGRAMA
DE SECUENCIA DEL PATRON MVC
EXPLICACIÓN
- El usuario activa el evento.
- El Controlador recibe el evento y lo traduce en una petición al
Modelo (aunque también puede llamar directamente a la vista).
- El modelo (si es necesario) llama a la vista para su actualización.
- Para cumplir con la actualización la Vista puede solicitar datos al
Modelo.
- El Controlador recibe el control.
PARTICIPANTES
Modelo: Representa los datos de la aplicación. Cualquier cosa que una aplicación
haga persistente es parte del modelo. El modelo también define la forma de
acceso a los datos (la lógica del negocio de la aplicación) para su
manipulación. No tiene por qué enterarse de cómo son presentados los datos por
la aplicación; únicamente proporciona el servicio para poder accederlos.
Generalmente está implementado empleando
EJB (Enterprise Java Beans),
Reglas de Negocio, acceso a los datos y Persistencia. (Beans, EJB, ORM)
Vista: Representa la presentación de la aplicación. La vista consulta al modelo
por contenido y lo muestra. La forma en
que el modelo será mostrado es definida por la
vista. La vista no es dependiente de cambios en los datos o en la lógica
de la aplicación, y permanece igual incluso si hay modificación en la lógica
del negocio. Generalmente está desarrollada empleando JSP. Gestión de la Interfaz de los datos a los
usuarios. html, jsp, javaScript, flex, ajax etc.)
Controlador: Todas las solicitudes de usuario a la aplicación pasan por el
controlador.
El controlador intercepta las solicitudes de la
vista y las dirige al modelo para la acción apropiada. Basados en los
resultados de la acción sobre los datos, el controlador redirige al usuario a
la vista siguiente. Está constituido por un servlet (ActionServlet), que
despacha las peticiones del usuario.
Gestiona eventos entre el Modelo y la vista. (struts Form,strutsAction,
struts-conf).
El
controlador Struts se encarga de tres tareas:
1. Validaciones simples: Consiste en validaciones simples sin acceder al modelo, se utiliza para
comprobar que se hayan ingresado todos los datos necesarios, para comprobar la
longitud de las contraseñas o de las direcciones de correo. Esto se logra extendiendo
la clase ActionForm
2. Validaciones Complejas: Se realiza extendiendo la clase base de struts llamada Action. A este
nivel se comprueba contra las reglas de negocio (modelo). Por ejemplo: Se
instancian objetos del modelo, se realizan consultas contra la base de datos y
se obtienen los errores etc.
3. Control de flujo o de Navegación: A través de un archivo de configuración
(struts-conf) se gestiona el flujo de navegación
entre páginas, que también se logra extendiendo la clase ActionForm y Action.
VENTAJAS
ü La implementación se realiza de forma modular.
ü Clara separación entre interfaz, lógica de negocio y de presentación.
ü Sus vistas muestran información actualizada siempre.
ü Cualquier modificación que afecte al dominio, como aumentar métodos o
datos contenidos, implica una modificación sólo en el modelo y las interfaces
del mismo con las vistas
ü Las modificaciones a las vistas no afectan al modelo de dominio
ü Sencillez para crear distintas representaciones de los mismos datos
ü Facilidad para la realización de pruebas unitarias de los componentes.
ü Reutilización de los componentes.
ü Simplicidad en el mantenimiento de los sistemas.
ü Facilidad para desarrollar prototipos rápidos.
ü Los desarrollos suelen ser más escalables
DESVENTAJAS
ü
Está sujeto a una
estructura predefinida, lo que a veces puede incrementar la complejidad del
sistema. Hay problemas que son más difíciles de resolver respetando el patrón
MVC
ü
Para desarrollar
una aplicación bajo el patrón de diseño MVC es necesario una mayor dedicación
en los tiempos iniciales del desarrollo (desarrollar un mayor número de
clases).
ü
MVC requiere la
existencia de una arquitectura inicial sobre la que se deben construir clases e
interfaces para modificar y comunicar los módulos de una aplicación.
ü
MVC es un patrón de
diseño orientado a objetos por lo que su implementación es sumamente costosa y
difícil en lenguajes que no siguen este paradigma.
EJEMPLO
Vista:
- la página HTML
Controlador:
- código que obtiene datos dinámicamente y genera el contenido HTML
Modelo:
- la información almacenada en una base de datos o en XML junto con
las reglas de negocio que transforman esa información (teniendo en cuenta
las acciones de los usuarios)
1.2.9
SERVICE
LOCATOR
Es
un componente que contiene referencias a los servicios y encapsula la lógica
que localiza dichos servicios, este
patrón es utilizado para obtener instancias de los servicios que necesitamos.
FUNCIONALIDAD
El
patrón de localización de servicios, es utilizado en el desarrollo de software
para encapsular los procesos involucrados en la obtención de un servicio con
una fuerte capa de abstracción. Este modelo utiliza un registro central
conocido como “Servicio de Localización”, que a petición devuelve la
información necesaria para realizar una tarea determinada.
VENTAJAS
ü Provee una manera de registrar servicios y mantener una referencia a
dichos servicios.
ü Una vez que el servicio es
registrado el service locator puede localizarlo.
ü Debe proveer una forma de localizar un servicio sin especificar el tipo.
ESTRUCTURA
PARTICIPANTES
ü Servicios: servicio actual que procesara solicitud
ü Contexto inicial: lleva la referencia al servicio que se utiliza para
fines de consulta
ü Servicio de localización: es un único punto de contexto para obtener los
servicios de búsqueda
ü Cache : almacena referencias de servicios a reutilizarlos
ü Cliente : invoca los servicios a través de service locator
DIAGRAMA DE SECUENCIAS
1.2.10 SESSION
FACADE
PROPOSITO
Proporciona una interfaz unificada para un conjunto de
interfaces de un subsistema. Define una interfaz de alto nivel que hace que el
subsistema sea más fácil de usar.
MOTIVACIÓN
Estructurar un sistema en un subsistema ayuda a
reducir la complejidad. Un tipo objetivo de diseño es minimizar la comunicación
y dependencias entre subsistemas. Un modo
de lograr esto es introduciendo un objeto fachada que proporcione una
interfaz única simplificada para los
servicios más generales del subsistema.
CARACTERISTICAS
ü Crea una fachada para encapsular las complejas
interrelaciones de los distintos elementos de negocio.
ü Proporciona un servicio uniforme y maneja el flujo
de ejecución de los subelementos.
VENTAJAS
ü Una de las ventajas de utilizar
este patrón a la hora de controlar los
permisos de los usuarios. Cada usuario tiene un rol (administrador, invitado,
usuario registrado, etc.) y, para controlar los permisos de cada rol, lo único
que hay que hacer es definir las
operaciones de cada rol en distintos sesión beans de la capa de control y
después, desde el deployment descriptor de los EJBs, mapear nuestros roles con
dichos sesión beans. La autenticación se realiza en la capa de interfaz.
DESVENTAJAS
ü Oculta a los clientes los
componentes del subsistema, reduciendo así el número de objetos con los que
tratan los clientes y haciendo que el subsistema sea más fácil de usar.
ü Promueve
un débil acoplamiento entre el subsistema y sus clientes. Muchas veces
los componentes de un subsistema sin que sus clientes se vean afectados, las
fachadas ayudan a estructurar en capas un sistema y las dependencias entre los
objetos. También pueden eliminar dependencias complejas o circulares. Esto
puede ser una consecuencia importante cuando el cliente y el subsistema se
implementan por separado
ü En los grandes sistemas de
software es vital reducir las dependencias de compilación. Queremos ahorrar
tiempo minimizando la recopilación cuando cambien las clases del subsistema.
Reducir las dependencias de compilación
con fachada puede limitar la compilación
necesaria para un pequeño cambio en un subsistema importante. Una fachada puede
simplificar portar sistemas en otras plataformas ya que es menos probable que
construir un subsistema requiera volver a construir todos los otros.
ü No impiden que las aplicaciones
usen las clases del subsistema en caso de que sea necesario. De este modo se
puede elegir entre la facilidad de uso y generalidad.
Estructura
IMPLEMENTACIÓN
Reducción del acoplamiento cliente-subsistema. El
acoplamiento entre clientes y el subsistema puede verse reducido todavía más
haciendo que Fachada sea una clase
abstracta con subclases concretas para diferentes implementaciones de un subsistema. De esa manera los clientes
pueden comunicarse con el subsistema a través de la interfaz de una clase
abstracta Fachada. Este acoplamiento abstracto evita que los clientes tengan
que saber que implementación de un subsistema están usando.
FUNCIONALIDAD
Clases del subsistema del subsistema públicas o
privadas. Un subsistema se parece a una clase en que ambos tienen interfaces y
los dos encapsulan algo – una clase encapsula estado y operaciones, mientras
que un subsistema encapsula clases. Y
del mismo modo resulta útil pensar en la interfaz pública y privada de una
clase, también podemos pensar en la interfaz pública y privada de un
subsistema.
La interfaz pública de un subsistema consiste en
una serie de clases a las que acceden todos los clientes; la interfaz privada
es solo para quienes vayan a ampliar el subsistema. La clase fachada es parte
de la interfaz pública, por supuesto pero no es la única. Otras clases del
subsistema también suelen ser públicas.
1.2.11
TRANSFER OBJECT
PROBLEMA
Las aplicaciones de la plataforma J2EE implementan
componentes de negocio del lado del servidor como beans de sesión y de entidad.
Algunos métodos expuestos por los componentes de negocio devuelven datos al
cliente. Algunas veces, el cliente invoca a los métodos get de un
objeto de negocio varias veces para obtener todos los valores de los atributos.
Los beans de sesión representan los servicios de
negocio y no se comparten entre usuarios. Un bean de sesión proporciona métodos
de servicios genéricos cuando se implementan para el patrón Session
Facade.
CAUSAS
ü
Todos los accesos a
un bean enterprise se realizan mediante interfaces remotos. Cada llamada a un
bean enterprise potencialmente es una llamada a un método remoto con sobrecarga
de red.
ü
Normalmente, las
aplicaciones tienen transacciones de lectura con mayor frecuencia que las de
actualización. El cliente solicita los datos desde la capa de negocio para su
presentación, y otros tipos de procesamientos de sólo-lectura. El cliente
actualiza los datos de la capa de negocio con mucha menos frecuencia con la que
los lee.
SOLUCIÓN
ü Utilizar un Transfer Object para
encapsular los datos de negocio. Se utiliza una única llamada a un método para
envíar y recuperar el Transfer Object. Cuando el cliente solicita los
datos de negocio al bean enterprise, éste puede construir el Transfer
Object, rellenarlo con sus valores de atributos y pasarlo por valor al cliente.
ü Los clientes normalmente solicitan más de un valor a
un bean enterprise. Para reducir el número de llamadas remotas y evitar la
sobrecarga asociada, es mejor el Transfer Objects para
transportar los datos desde el bean enteprise al cliente.
ü Cuando un bean enterprise utiliza un Transfer
Object, el cliente hace una sola llamada a un método remoto del bean
enterprise para solicitar el Transfer Object en vez de
numerosas llamadas remotas para obtener valores de atributos individuales
ESTRUCTURA
Participantes
ü El Transfer Object lo construye
bajo pedido el bean enterprise y lo devuelve al cliente remoto. Sin
embargo, el patrón Transfer Object puede adoptar varias estrategias,
dependendiendo de los requerimientos
Client
ü Representa al cliente del bean enterprise. El
cliente puede ser una aplicación final de usuario, como es el caso de una
aplicación que ha sido diseñada para acceder directamente a beans enterprise.
El cliente puede utilizar Business Delegate u
otro BusinessObject diferente.
BusinessObject
ü Representa un rol en este patrón que puede cumplir
un bean de sesión, un bean de entidad, o un Data Access Object
(DAO). BusinessObject es el responsable de crear el Transfer
Object y devolverlo al cliente bajo pedido.
El BusinessObject también podría recibir datos desde el cliente en la
forma de un Transfer Object y utilizar esos datos para
realizar una actualización.
TransferObject
ü TransferObject es un objeto Java serializable
referenciado como un Transfer Object. Una clase Transfer
Object podría proporcionar un constructor que acepte todos los
atributos requeridos para crear el Transfer Object. El constructor
podría aceptar todos los valores de atributos del bean de entidad para el que
se ha diseñado el Transfer Object
DIAGRAMA DE SECUENCIAS
.
CONSECUENCIAS
ü Transfiere
Más Datos en Menos Llamadas Remotas: En
lugar de realizar múltiples llamadas sobre la red
al BusinessObject para obtener los valores de los atributos, esta
solución proporciona una sola llamada a un método.
ü Reduce
el Tráfico de Red : Un Transfer
Object transfiere los valores desde el bean de entidad al cliente en una
llamada a un método remoto. El Transfer Object actúa como un
transportista de datos y reduce el número de llamadas remotas requeridas para
obtener los valores de los atributos del bean; y esto significa un mejor
rendimiento de la red.
1.2.12 VALUE LIST HANDLER
PROBLEMA
ü La mayoría de las aplicaciones de la plataforma J2EE tienen un
requerimiento de búsqueda y consulta para buscar y listar ciertos datos. En
algunos casos, dichas operaciones de búsqueda y consulta podrían traer
resultados que pueden ser bastante grandes. No es práctico devolver toda la
hoja de resultados cuando los requerimientos del cliente son moverese por los
resultados, en vez de procesar el conjunto completo. Normalmente, un cliente
usa los resultados de una consulta para propósitos de sólo-lectura, como
mostrar una lista de resultados.
ü Muchas veces el cliente sólo ve los primeros registros que devuelve la
búsqueda, y podría descargar los registros restantes e intentar otra nueva
consulta. La práctica de obtener uns lista de valores representados en un bean
de entidad llamando al método ejbFind(), que devuelve
una collection de objetos remotos, y luego llamar a cada bean de
entidad para obtener el valor, consume muchos recursos de red y se considera
una mala práctica.
ü La aplicación cliente necesita una facilidad de consulta eficiente para
evitar tener que llamar al método ejbFind() de cada bean e invocar a
cada objeto remoto devuelto.
ü Se necesita una mecanismo de caché en la capa-servidor para servir a los
clientes que no pueden recibir y procesar el cojunto de resultados completo.
ü Se puede optimizar una consulta que se ejecuta repetidamente sobre unos
datos razonablemente estáticos para proporcionar resultados más rápidos. Esto
depende de la aplicación y de la implementación de este patrón.
CAUSAS
ü La aplicación cliente necesita una facilidad de consulta eficiente para
evitar tener que llamar al método ejbFind() de cada bean e invocar a
cada objeto remoto devuelto.
ü Se necesita una mecanismo de caché en la capa-servidor para servir a los
clientes que no pueden recibir y procesar el cojunto de resultados completo.
ü Se puede optimizar una consulta que se ejecuta repetidamente sobre unos
datos razonablemente estáticos para proporcionar resultados más rápidos. Esto
depende de la aplicación y de la implementación de este patrón.
SOLUCIÓN
Utilizar un Value List Handler para controlar la
búsqueda, hacer un caché con los resultados, y proporcionar los resultados al
cliente en una hoja de resultados cuyo tamaño y desplazamiento cumpla los
requerimientos del cliente.
Estructura
PARTICIPANTES
ValueListIterator
Este interface podría proporcionar la facilidad de
iteración con los siguientes métodos de ejemplo:
ü getSize() obtiene el tamaño de la hoja de resultados.
ü getCurrentElement() obtiene el Transfer Object actual de
la lista.
ü getPreviousElements(int howMany) obtiene una colección
de Transfer Objects que son anteriores en la lista al elemento actual.
ü getNextElements(int howMany) obtiene una colección de Transfer
Objects que son posteriores en la lista al elemento actual.
ü resetIndex() reinicia el índice para ir al inicio de la lista.
ü Dependiendo de las necesidades, se pueden incluir otros métodos de
conveniencia en el interface ValueListIterator.
ValueListHandler
ü Este es el objeto que implementa el interface ValueListIterator. ValueListHandlerejecuta
la consulta requerida cuando se lo solicita el cliente. Obtiene los resultados
de la consulta, que maneja en una colección privada representada por el
objeto ValueList.ValueListHandler crea y manipula la colección ValueList.
Cuando el cliente solicita los resultados, ValueListHandler obtiene
los Transfer Objects desde el ValueList cacheado, crea una
nueva colección de Transfer Objects, serializa la colección y la envía de
vuelta alcliente. ValueListHandler también sigue la pista del índice
actual y del tamaño de la lista.
DataAccessObject
ü ValueListHandler puede hacer uso de un DataAccessObject: para
mantener separada la implementación del acceso a la base de
datos. DataAccessObject proporciona un API sencillo para acceder a la
base de datos (o cualquier otro almacenamiento persistente), ejecuta consultas
y recupera resultados.
ValueList
ü ValueList es una colección (una lista) que contiene los resultados de la
consulta. Los resultados se almacenan como objetos Transfer Objects. Si
falla la consulta y no se devuelven resultados, entonces esta lista está vacía.
El bean de sesión ValueListHandler puede
almacenar ValueList para evitar repeticiones innecesarias de la
consulta.
TransferObject
ü TransferObject representa una vista de un registro individual de los
resultados de la consulta. Es un objeto serializable no modificable que
proporciona un espacio para los datos de los atributos de cada registro.
CONSECUENCIAS
ü Proporciona
Alternativas a los métodos find() de EJB para Grandes Consultas.
ü Crea un Caché de
Resultados de la Consulta en el Lado del Servidor
Se necesita cachear los resultados obtenidos de la ejecución de la consulta cuando un cliente debe mostrarlos en pequeñas partes en vez de una gran lista
Se necesita cachear los resultados obtenidos de la ejecución de la consulta cuando un cliente debe mostrarlos en pequeñas partes en vez de una gran lista
ü Proporciona una Mayor
Flexibilidad de Consulta
DIAGRAMA
DE SECUENCIAS
1.2.13 VIEW HELPER
Propósito
Los helpers
JavaBean se utilizan para ayudar en la recuperación de contenido y en el
almacenamiento y adaptación del modelo para la vista.
Los helpers JavaBean también se
utilizan frecuentemente como objetos Command.
Contexto
El
sistema crea el contenido de la presentación, lo que requiere el procesamiento
de datos de negocio dinámicos.
Los cambios en la capa de presentación ocurren muy
frecuentemente y son difíciles de desarrollar y mantener cuando la lógica de
acceso a los datos de negocio y la lógica del formateo de la presentación se
mezclan. Esto hace el sistema menos flexible, menos reutilizable, y
generalmente menos adaptable a los cambios.
Mezclar la lógica de negocio y de sistema con el
procesamiento de la vista reduce la modularidad y también proporciona una pobre
separación de los roles entre los equipos de producción Web y de desarrollo de
software.
ü Los requerimientos de asimilación
de datos de negocio no son triviales.
o
Embeber
la lógica de negocio en la vista promueve un tipo de reutilización del tipo
copiar-y-pegar. Esto causa problemas de mantenimiento y errores porque una
pieza de lógica se reutiliza en la misma vista o en otra diferente simplemente
duplicándola en la nueva localización.
o
Es
deseable promover una separación limpia de labores teniendo diferentes
individuos cumpliendo los roles de miembros de un equipo de desarrollo de
software y de producción Web.
o
Una vista
comúnmente se utiliza para responder a una petición de negocios particular.
SOLUCIÓN
Una vista contiene código
de formateo, delegando sus responsabilidades de procesamiento en sus clases de
ayuda, implementadas como JavaBeans o etiquetas personalizadas. Las clases de
ayuda o helpers también almacenan el modelo de datos intermedio de la
vista y sirven como adaptadores de datos de negocio.
Hay varias estrategias para implementar el
componente de la vista. La estrategia JSP View siguiere utilizar una JSP como
el componente vista. Esta es la estrategia preferida, y es la que se utiliza
más comunmente. La otra estrategia principal es la estrategia Servlet View, que
utiliza un servlet como la vista.
Encapsular la lógica de negocio en un helper
en lugar de hacerlo en la vista hace que nuestra aplicación sea más modular y
facilita la reutilización de componentes. Varios clientes, como controladores y
vistas, podrían utilizar el mismo helper para recuperar y adaptar
estados del modelo similares para su presentación en varias vistas. La única
forma de reutilizar la lógica embebida en una vista es copiando y pegando en
cualquier lugar. Además, la duplicación mediante copiar-y-pegar hace que un
sistema sea difícil de mantener, ya que necesitamos corregir en muchos sitios
el mismo error potencial.
Una señal de que podríamos necesitar aplicar este
patrón al código existente es cuando el código scriptlet domina en la vista
JSP. Ya que el objetivo general cuando se aplica este patron, es el
particionamiento de la lógica de negocio fuera de la vista. Mientras alguna
lógica está mejor cuando se encapsula dentro de objetos helper, otra
lógica está mejor situándola en un componente centralizado que se sitúa delante
de las vistas y los helpers -- esta podría la lógica que sea común entre
varias peticiones, como los chequeos de autentificación o servicios de logs,
por ejemplo.
Si no se emplea un controlador separado en la
arquitectura, o si no se utiliza para manejar todas las peticiones, entonces el
componente vista se convierte en el punto de contacto inicial para manejar
algunas peticiones. Para ciertas peticiones, particularmente aquellas que
implican un procesamiento mínimo, este escenario funcionará bien. Típicamente,
esta situación ocurre cuando páginas que están basadas en información estática,
como la primera de un conjunto de páginas que se servirán a un usuario para
obtener alguna información. .
El patrón View Helper se enfoca en
recomendar formas de particionar las responsabilidades de nuestras
aplicaciones.
La siguiente figura muestra el diagrama de
secuencia que represetna el patrón View Helper. Normalmente un
controlador media entre el cliente y la vista. Aunque en algunos casos, no se
utiliza un controlador y la vista se convierte en el punto de contacto inicial
para manejar peticiones.
Como se
ha podido observar en el diagrama de clases, podrían no haber helpers
asociados con una vista. En este caso simple, la página podría ser
completamente estática o incluir una muy pequeña cantidad de scriptles. Este
escenario se describe en el siguiente diagrama de secuencia:
Una vista representa y muestra información al
cliente. La información que se utiliza en un display dinámico se recupera de un
modelo. Los helpers soportan vistas encapsulando y adaptando un modelo
para utilizarlo en un display.
Un helper es el responsable de ayudar a la
vista o al controlador a completar su procesamiento. Así los helpers
tienen numerosas responsabilidades, incluyendo la obtención de los datos
requeridos por la vista y su almacenamiento en el modelo intermedio, en cuyo
caso algunas veces nos podemos referir al helper como un Bean de Valor.
Además, los helpers podrían adaptar este modelo de datos para que los
utilizara la vista. Los helpers pueden servir peticiones de datos desde
la vista simplemente proporcionando acceso a los datos o fomateando los datos
como contenido Web.
Una vista podría trabajar con cualquier número de helpers,
que normalmente están implementados como JavaBeans (JSP 1.0+) y etiquetas
personalizadas (JSP 1.1+). Además, un helper podría representar un
objeto Command o un Tranformador XSL, que se utiliza en combinación con una
hoja de estilo para adaptar y convertir el modelo en el formato apropiado.
Un Bean de Valor es un otro nombre para un helper
que es responsable de contener el estado del modelo intermedio para que lo
utilice una vista. Un caso típico, es el que tiene un servicio de negocio que
devuelve un bean de valor en respuesta a esta petición. Este caso, el Bean de
valor cumple el rol de un objeto Transfer.
BusinessService
El servicio de negocio es un rol que cumple el
servicio al que está accediendo el cliente. Típicamente, se accede al servicio
de negocio mediante un Delegado de Negocio. El rol del delegado de negocio es
proporcionar control y protección para el servicio de negocio (podremos ver el
patrón Business Delegate más adelante).
- Mejora
el Particionamiento de la Aplicación, la Reutilización y el Mantenimiento
Utilizar helpers resulta en una clara separación de la vista del procesamiento de negocio en una aplicación. Los helpers, en forma de JavaBeans (JSP 1.0+) y etiquetas personalizadas (JSP 1.1+), proporcionan un lugar externo para que la vista encapsule la lógica de negocio. Por el contrario, el código en scriptlets dentro de las páginas JSP, emborrona ampliamente la situación, especialmente en gandes proyectos. - Mejora
la Separación de Roles:Separar la lógica del formateo de la lógica de negocio de la
aplicación reduce las dependencias podrían tener los individuos que juegan
los diferentes roles en los mismos recursos. Por ejemplo, un desarrollador
de software podría poseer código que está embebido dentro de marcas HTML,
mientras que un miembro del equipo de producción Web podría necesitar
modificar la distribución de la página y diseñar componentes que están
mezclados con la lógia de negocios. Ningún individuo que cumpla estos
roles podría estar familiarizado con las implementaciones específicas del
trabajo del otro individuo, y asi se evita el riesgo de introducir bugs
mediante modificaciones accidentales del sistema.
PATRONES RELACIONADOS
- Business Delegate
Los componentes helper necesitan métodos de acceso al API de servicios de negocio. - Dispatcher View y Service to Worker
Cuando sea deseable el control centralizado para manejar problemas como la seguridad, el control del carga de trabajo, la recuperación de contenidos y la navegación, debemos considerar la utilización de los patrones Dispatcher View o Service to Worker. - Front Controller
Este patrón está emparejado con el patrón View Helper para crear los patrones Dispatcher View o Service to Worker.
1.2.14
FÁBRICA ABSTRACTA (ABSTRACT FACTORY)
PROPÓSITO
Proporciona
una interfaz para crear familias de objetos relacionados o que dependen entre
sí, sin especificar sus clases concretas.
Una de las operaciones más comunes al programar con
objetos es, lógicamente, la creación de los objetos. Sin embargo, esta
operación es en sí misma un foco de acoplamiento.
Cuando desde un fragmento de código C invocamos la creación de un objeto de la
clase A estamos acoplando ese código con el de la clase A. Si posteriormente
deseamos cambiar el objeto de clase A por otro de otra clase que cumpla su
misma interfaz no podremos hacerlo sin cambiar el código C.
Para evitar este problema se suele delegar la
creación de los objetos a otro objeto que se denomina fábrica (factory). De
esta manera desde el código C no creamos
el objeto A directamente, sino que se lo pedimos a la clase fábrica.
Evidentemente, para evitar el acoplamiento de la fábrica con el código C, la
propia fábrica deberá obtenerse por parámetros.
Cada
producto concreto se crea desde un constructor específico
Aplicabilidad
Use el patrón cuando:
ü Un sistema debe ser independiente de cómo se crean, componen y
representan sus productos.
ü Un sistema debe ser configurado con una familia de productos entre
varias.
ü Una familia de objetos producto relacionados está diseñada para ser usada
conjuntamente, y es necesario hacer cumplir esta restricción.
ü Quiere proporcionar una biblioteca de clases de productos, y solo quiere
revelar sus interfaces, no sus implementaciones.
Ejemplos:
PARTICIPANTES
FabricaAbstracta
(fabricadeutiles)
ü Declara una interfaz para operaciones que crean objetos producto
abstracto.
FabricaConcreta
(fabricaDeUtiliesMotif, FabricaDeUtilesPM)
ü Implementa las operaciones para crear objetos producto concreto.
ProductoAbstracto (ventana BarraDeDesplazamiento)
ü Declara una interfaz para un tipo de objeto producto.
ProductoConcreto (VentanaMotif, barraDeDesplazamientoModif)
ü Define un objeto producto para que sea creado por la fábrica
correspondiente.
ü Implementa la interfaz productoAbstracto
Cliente
Solo usan interfaces declaradas por las clases
fabricaAbstracta y productoAbstracto.
CONSECUENCIAS
ü Aisla las clases concretas
ü Facilita el intercambio de familias de productos
ü Promueve la consistencia entre productos
ü Es dificil dar cabida a nuevos tipos de productos
EJEMPLO
De una fabrica de pizzas en donde
existen dos pizerias una de NY y la otra de chicago y cada una con sus
respectivos tipos de pizzas.
1.2.15
ADAPTADOR O ENVOLTORIO (ADAPTER O WRAPPER)
El patrón Envoltorio se
utiliza cuando se desea que una clase utilice otra aunque ésta no cumple cierta interfaz obligatoria.
PROPÓSITO:
Convierte
la interfaz de una clase en otra interfaz que es la que esperan los clientes.
Permite que cooperen clases que de otra forma no podrían tener interfaces
incompatibles.
APLICABILIDAD
Debería de usar el patrón
cuando:
ü Se quiere usar una clase existente y su interfaz no
concuerda con la que necesita.
ü Se quiere crear una clase reutilizable que coopere
con clases no relacionadas o que no han sido previstas, es decir, clases que no
tienen por qué tener interfaces compatibles.
ü (Solamente en el caso de un adaptador de objetos) es
necesario usar varias subclases existentes, pero no resulta práctico adaptar su
interfaz heredando de cada una de ellas. Un adaptador de objetos puede adaptar
la interfaz de su clase padre.
Un adaptador de objetos se
basa en la composición de objetos:
PARTICIPANTES
Objeto (forma)
ü Define la interfaz específica del dominio que usa el cliente
Cliente
(editorDeDibujo)
ü Colabora con objetos que se ajustan a la interfaz objetivo
Adaptable
(vista Texto)
ü Define una interfaz existente que necesita ser adaptada.
Adaptador
(forma texto)
ü Adapta la interfaz de adaptable a la interfaz objetivo.
EJEMPLO:
Por
ejemplo, en el diagrama adjunto la clase Cliente solo puede utilizar objetos
que cumplan la interfaz InterfazAmiga,
pero se desea utilizar sobre la clase Extraña. Para ello, se crea la clase Adaptador, que contiene un objeto de la clase
Extraña pero que implementa la interfaz Amiga. De esta forma, la clase Usuaria utiliza,
indirectamente, la clase Extraña.
El cliente accede a la clase extraña utilizando una interfaz que conoce y que envuelve a la clase extraña.
Este
patrón se utiliza cuando deseamos almacenar un tipo primitivo de Javaen un
derivado de Collection.
EJEMPLO
Por ejemplo, supongamos que deseamos almacenar
un int en un Vector. Como los enteros no son elementos de la clase Objectes necesario envolverlos en otra clase
que contenga el entero y que, al derivar de
Object, sí pueda ser insertada en el vector.
Por
eso, y por otras razones, en Java existen clases como Integer, Float, Booleano
Character que son envoltorios de los tipos primitivos.
En este caso
el adaptador es Integery adapta al tipo primitivo int para que pueda ser usado
como un Object
1.2.16
DECORADOR (DECORATOR)
El patrón Decorador permite añadir nueva
funcionalidad a una familia de componentes manteniendo la interfaz del componente.
MOTIVACIÓN
A veces se desea adicionar responsabilidades a un
objeto, pero no a toda la clase. Las responsabilidades se pueden adicionar por
medio de los mecanismos de herencia, pero este mecanismo no es flexible porque
la responsabilidad es adicionada
estáticamente. A responsabilidad. La solución flexible es la de ordenar el
objeto con otro objeto que es el que adiciona la nueva responsabilidad. Este
nuevo objeto es el decorador.
Aplicabilidad
ü El decorador se debe usar para:
ü Adicionar responsabilidades a objetos individuales dinámicamente sin
afectar otros objetos.
ü Para agregar responsabilidades que pueden ser retiradas.
ü Cuando no es practico adicionar responsabilidades por medio de la
herencia.
Participantes y
estructura.
La clase Componente es abstracta, la clase Componente Concreto
implementa un comportamiento determinado.
La clase Decorador contiene
un Componente en su interior. Cuando se
Solicita una operación al objeto de la clase Decorador esta la deriva al Componente
que contiene. Las clases derivadas de Decorador son los verdaderos
Decoradores que implementan una nueva funcionalidad añadida al Componente que contienen.
PARTICIPANTES:
Componente: interfaz común a todas las clases susceptibles de
ser ampliadas con el decorador.
ComponenteConcreto: son las clases cuya funcionalidad se puede extender
y en las que se delega en última instancia para realizar las operaciones
propias de las clase.
Decorador: clase abstracta que declara la estructura común a
todos los decoradores y declara(o implementa, según sea el caso) la
responsabilidad de mantener una referencia al objeto que se extiende. Es
posible que sobrecargue todos los métodos de la clase componente con llamadas
al componente concreto, de forma que aquellos métodos cuya funcionalidad no se
extiende simplemente llaman a los originales.
DecoradorConcreto1 y
decoradorConcreto2: con clases
concretas que heredan de decorador e
implementan las extensiones de funcionalidad de la clase original ComponenteConcreto.
EJEMPLO: PROBLEMA QUE
SOLUCIONA
Supongamos
que tenemos una clase existente Ventana y queremos añadirle funcionalidad para
que muestre un borde alrededor. Podemos crear una subclase VentanaConBorde
que herede de Ventana.
Supongamos
que surge la necesidad de crear una ventaja que muestre un pequeño botón de
ayuda con un signo de interrogación (?) en su parte superior.
Entonces tenemos las
siguientes opciones:
1
Crear otra subclase
de Ventana: VentanaConBotonDeAyuda.
Problema: no cubre la necesidad de tener ventanas con bordes
y botón de ayuda a la vez.
2
Crear una subclase
de VentanaConBorde:
VentanaConBordeYBotonDeAyuda.
Problema: no tenemos una ventana con botón de ayuda y sin
borde.
3
Crear clases para
todas las combinaciones posibles de funcionalidades.
Problema: Con este ejemplo tendríamos posibles de
funcionalidades. VentanaConBotonDeAyuda y VentanaConBordeyBotonDeAyuda; con
tres funcionalidades tendríamos 8 clases y con 4, 16 clases. Para n
funcionalidades se necesitan 2n clases.
IMPLEMENTACIÓN
El patrón decorador soluciona este problema de un
amanera mucho más sencilla y extensible Se crea a partir de Ventana la subclase
abstracta VentanaDecorador y, heredando de ella, BordeDecorador y
BotonDeAyudaDecorador.
Ventana Decorador encapsula el comportamiento de Ventana y utiliza composición recursiva para que sea posible añadir tantas “capas” de Decorador como se desee. Podemos crear tantos Decoradores como queremos heredando de VentanaDecorador.
1.2.17
COMPOSICIÓN (COMPOSITE)
Este
patrón se puede definir:
Como jerarquías de objetos
que comparten una interfaz y tales que algunos de los objetos pueden formar
parte de otros. La siguiente figura describe este patrón. Obsérvese que tanto
los objetos de la clase Elemento como
los de Compuesto cumplen la interfaz Componente, pero los de clase Compuesto
además puede contener dentro otros objetos de la clase Componente.
Propósito:
Compone
objetos en estructuras de árbol para representar jerarquías de parte-todo.
Permite que los clientes traten de manera uniforme a los objetos individuales y
compuestos.
APLICABILIDAD
Use
el patrón cuando:
ü Quiera representar jerarquías de objetos parte-todo.
ü Quiera que los clientes sean capaces de obviar las
diferencias entre composiciones de objetos y los objetos individuales. Los
clientes trataran a todos los objetos de la estructura compuesta de manera
uniforme.
ESTRUCTURA:
La
clase componente proporciona la interfaz común. Las clases derivadas
pueden ser de dos tipos: compuestos (que a su vez agrupan a otros
componentes) o simples hojas.
EJEMPLOS:
Ejemplo1: En una jerarquía de componentes de dibujo puede ser importante que todos los elementos que se puedan dibujar compartan cierta interfaz, pero además también es importante que unos elementos puedan formar parte de otros(los objetos línea forman parte del objeto cuadrado).
Explicación:
La
clase dibujo define una agregación de objetos gráfico. Dibujo
implementa dibujar para que llame al Dibujar de sus hijos, y añade operaciones
relacionadas con los hijos. Como la interfaz de Dibujo se ajusta a la
interfaz de gráfico, los objetos dibujo pueden componer
recursivamente otros Dibujos.
La estructura de objetos compuestos puede aparecerse a esto:
Participantes:
Componente (grafico)
ü Declara la interfaz de los objetos de la composición.
ü Implementa el comportamiento predeterminado de la interfaz que es común a
todas las clases.
ü Declara una interfaz para acceder a sus componentes hijos y gestionarlos.
ü (opcional) define una interfaz para acceder al padre de un componente en
la estructura recursiva y si es necesario, la implementa.
Hoja (rectángulo, línea, texto, etc.)
ü Representa objetos en la composición. Una hoja no tiene hijos.
ü Define el comportamiento de los objetos primitivos de la composición.
Compuesto
(dibujo)
ü Define el comportamiento de los componentes que tienen hijos.
ü Almacena componentes hijos.
ü Implementa las operaciones de la interfaz componente relacionadas con los
hijos.
Cliente
Manipula objetos en la composición a través de la
interfaz componente.
Consecuencias
ü Define jerarquías de clases formadas por objetos
primitivos y compuestos.
ü Simplifica el cliente
ü Facilita añadir nuevos tipos de componentes
ü Puede hacer que un diseño sea demasiado general.
1.2.18
ITERADOR (ITERATOR)
El patrón Iterador permite definir objetos para
realizar esta tarea. Un objeto iterador es una especie de apuntador que se
puede iniciar apuntando al primer elemento de una colección y que puede desplazarse
hasta el último elemento de la misma.
PROPÓSITO
Proporciona un modo de acceder secuencialmente a los
elementos de un objeto agregado sin exponer su representación interna. La clase
iterador define una interfaz para acceder a los elementos de la lista. Un
objeto iterador es el responsable de saber cuál es el elemento actual; es
decir, sabe que elementos ya han sido recorridos.
La IDEA CLAVE DE ESTE PATRÓN es tomar
la responsabilidad de acceder y recorrer el objeto lista y poner dicha responsabilidad
en un objeto iterador.
Java
dispone de la interfaz Iterador, la cual está implementada por las diferentes
clases de Collection. En realidad, estas clases son fábricas de
iteradores que permiten recorrerlas.
ESTRUCTURA
El
iterador concreto permite recorrer el contenedor concreto
PARTICIPANTES:
Iterador
ü Define una interfaz para recorrer los elementos y
acceder a ellos.
IteradorConcreto
ü Implementa la interfaz iterador.
ü Mantiene la posición actual en el recorrido del
agregado.
Agregado
ü Define una interfaz para crear un objeto iterador.
AgregadoConcreto
Implementa la interfaz de
creación de iterador para devolver una instancia del iteradorConcreto
apropiado.
APLICABILIDAD
ü Use el patrón iterador:
ü Para acceder al contenido de un objeto agregado sin
exponer su representación interna.
ü Para permitir varios recorridos sobre objetos
agregados.
ü Para proporcionar una interfaz uniforme para
recorrer diferentes estructuras agregadas(es decir, para permitir la iteración
polimórfica).
CONSECUENCIAS:
ü Permite variaciones en el recorrido de un agregado.
ü Los iteradores simplifican la interfazAgregado.
ü Se puede hacer más de un recorrido a la vez sobre un agregado.
1.2.19
ESTRATEGIA (STRATEGY)
El patrón Estrategia permite organizar dichas
familias de algoritmos, de manera que compartan una interfaz para que luego los
clientes de dichas clases puedan utilizarlos indistintamente.
PROPÓSITO
Define una familia de algoritmos, encapsula cada uno
de ellos y los hace intercambiables. Permite que un algoritmo varié
independiente de los clientes que lo usa.
PARTICIPANTES:
Estrategia(componedor)
ü Declara una interfaz comun a todos los algoritmos
permitidos. El contexto usa esta interfaz para llamar al algoritmo definido por
una estrategiaConcreta.
estrategiaConcreta(componedorSimple, ComponedorTec, componedirMatrix)
contexto(composicion)
ü se configura con un objeto estrategiaConcreta
ü mantiene una referencia a un objeto estrategia
ü puede definir una interfaz que permita a la estrategia
acceder a sus datos.
APLICABILIDAD
Use
el patrón cuando:
ü Muchas clases relacionadas difieren solo en su comportamiento.
ü Se necesitan distintas variantes e un algoritmo.
ü Un algoritmo usa datos que lo clientes no deberían conocer
ü Una clase define muchos comportamientos, y estos se representan como
múltiples sentencias condicionales en sus operaciones.
EJEMPLO
Un ejemplo de uso del patrón Estrategia puede ser la
implementación de los diferentes algoritmos de ordenación de una lista de números.
Gracias al patrón Estrategia el usuario del contexto puede modificar su
criterio de ordenación de forma dinámica.
Un
usuario puede utilizar cualquiera de los algoritmos que cumplan la interfaz de
ordenación a través del objeto Contexto.
CONSECUENCIAS: ventajas e inconvenientes
ü Familias de algoritmos relacionados
ü Una alternativa a la herencia
ü Las estrategias eliminan las sentencias
condicionales
1.2.20
COMANDO (COMMAND)
Este
patrón encapsula las operaciones que realiza un objeto de forma que éstas sean
a su vez objetos que cumplen una misma interfaz.
Esto permite realizar, de manera sencilla, tareas
como:
ü Agrupar
ü Encolar operaciones
ü Deshacer operaciones
ü Parametrizar otros objetos con dichas operaciones de forma sencilla.
Además,
fomenta que añadir nuevos comandos sea una tarea simple y aislada.
PROPÓSITO:
Encapsula una petición en un objeto, permitiendo así
parametrizar a los clientes con diferentes peticiones, hacer cola o llevar un
registro de la peticiones, y poder deshacer las operaciones.
Aplicabilidad
Use el patrón cuando se
quiera:
ü Parametrizar objetos con una acción a realizar.
ü Cuando se quiera deshacer las operaciones.
ü Cuando se quiera registrar los cambios de manera que se puedan volver a
aplicar en caso de una caída al sistema.
Diagrama
de clases
Del
patrón Comando
PARTICIPANTES:
Orden
ü Declara una interfaz para ejecutar una operación.
Orden concreta(ordenPegar,ordenAbrir)
ü Define un enlace entre un objeto receptor y una accion.
ü Implementa ejecurar invocando la correspondiente
operación u opraciones del receptor.
Cliente(aplicacion)
ü Crea un objeto OrdenConcreto y establece su receptor.
Invocador(ElementoDeMenu)
ü Le pide a la orden que ejecute la peticion
Receptor(documento, aplicacion)
ü Sabe como llevar a cabo las operaciones asociadas a una
peticion. Cualquier clase puede hacer actuar como receptor.
COLABORADORES:
ü El cliente crea un objeto OrdenConcreta y especifica su receptor.
ü Un objeto invocador almacena el objeto OrdenConcreta.
ü El invocador envia una peticion llamando a ejecutar
sobre la orden. Cuando las ordenes se pueden deshacer, OrdenConcreta guarda el
estado para deshacer la orden antes de llamar a ejecuta.
ü El objeto ordenConcreta invoca operaciones de si
receptor para llevar a cavo la peticion.
El diagrama muestra las
interacciones entre estos objetos, ilustrando como orden descopla el invocador
del receptor(y de la petición que este lleva a cabo)
CONSECUENCIAS:
ü Orden desacopla el objeto que invoca la operación de aquel que sabe cómo
realizarla.
ü Las órdenes son objetos de primera clase. Pueden ser manipulados y
extendidos como cualquier otro objeto.
ü Se pueden ensamblar órdenes en una orden compuesta.
ü Es fácil añadir nuevas órdenes, ya que no hay que cambiar las clases
existentes
EJEMPLO, para ordenar los
comandos que se pueden ejecutar desde un intérprete de consola. Si el
intérprete utiliza los comandos solo a través de la interfaz común, sin conocer
en cada momento el comando concreto que se está ejecutando, una de las ventajas
que se obtienen consiste en que el número de comandos puede crecer sin
modificar dicho interprete
El
objeto de clase Intérprete sólo necesita conocer la interfaz de la claseComandoShell.
En este caso, el sistema operativo sería el receptor y el interprete sería el
ejecutor.
1.2.21
OBSERVADOR (OBSERVER)
Este
patrón crea una relación entre objetos en la que uno de ellos es observado por
el resto, de manera que cuando el objeto observado cambia el
resto puede automáticamente realiza alguna acción.
PROPÓSITO
Define una dependencia de uno a muchos entre
objetos, de forma que cuando un objeto cambie de estado se modifique y se
actualicen automáticamente todos los objetos que dependen de él.
APLICABILIDAD
Use el patrón
observer en cualquiera de las situaciones siguientes;
ü Cuando una abstracción tiene dos aspectos y uno depende el otro.
Encapsula estos aspectos en objetos separador permite modificarlos y
reutilizarlos de forma independiente.
ü Cuando un cambio en un objeto requiere cambiar otros, y no sabemos
cuántos objetos necesitan cambiarse.
ü Cuando un objeto debería ser capaz de notificar a otros sin hacer
suposiciones sobre quienes son dichos objetos. En otras palabras, cuando no
queremos que estos objetos estén fuertemente acoplados.
ESTRUCTURA
PARTICIPANTES
Sujeto
ü Conoce a sus
observadores. Un sujeto puede ser observado por cualquier número de objetos
observado.
ü Proporciona una
interfaz para asignar y quitar objeto observador.
ü Observador
ü Define una interfaz
para actualizar los objetos que deben ser notificados ante cambios en un
sujeto.
SujetoConcreto
ü Almacena el estado de
interés para los objetos ObservadorConcreto.
ü Envía una
notificación a sus observadores cuando cambia su estado.
ObservadorConcreto
ü Mantiene una
referencia a un objeto SujetoConcreto
ü Guarda un estado que
debería ser consistente con el del sujeto
ü Implementa la
interfaz de actualización del observador para mantener su estado consistente
con el del sujeto.
Ejemplo:
Bibliografía
GAMMA, E. (2003). PATRONES DE DISEÑO. En E. GAMMA, PATRONES
DE DISEÑO (pág. 384). MADRID: PEARSON.
Serrano, J. F. (2013). Técnicas Avanzadas de
Diseño de Software.
Torrijos, R. L.
(1998-2013). Programacion en castellano. Recuperado el 05 de julio de
2013, de Programacion en castellano: www.Catálogo de Patrones de Diseño J2EE.
I.- Capa de Presentación. Programación en Castellano..htm
No hay comentarios:
Publicar un comentario