Ricardo D.

Masabel Avendaño
Microsoft Certified Professional
Agenda
Repaso
Iterator
Composite
Integración de la IU con Model-View-Controller
Observer
Command
Adapter
Resumen
Lo que vimos en la sesión anterior
Template Method
Usando el Template Method, se define una
estructura de herencia en la cual la superclase
sirve de plantilla ("Template" significa
plantilla) de los métodos en las subclases. Una
de las ventajas de este método es que evita la
repetición de código, por tanto la aparición de
errores.
Factory
Este patrón delega en una clase la
responsabilidad de creación de objetos de
otras clases.
No delega en subclases y sus métodos
pueden ser estáticos
Puede evolucionar a un Factory Method o a un
Abstract Factory.
Factory

+CreateObjectA()
+CreateObjectB()
+CreateObjectC()
Factory Method
Factory Method define una interfaz para crear
objetos, pero deja que sean las subclases
quienes decidan qué clases instanciar;
permite que una clase delegue en sus
subclases la creación de objetos.
Factory Method
 Usar cuando:
 Una clase no puede prever la clase de objetos que debe crear.
 Una clase quiere que sean sus subclases quienes especifiquen
los objetos que ésta crea.
 Las clases delegan la responsabilidad en una de entre varias
clases auxiliares, y queremos localizar concretamente en qué
subclase de auxiliar se delega.
Abstract Factory
El patrón Abstract Factory proporciona una
interfaz para crear familias de objetos
relacionados o que dependen entre sí, sin
especificar sus clases concretas.
La solución que propone coonsiste en
coordinar la creación de familias de objetos.
Establecer una forma para quitar las reglas de
cómo realizar la instanciación fuera del objeto
que está usando los objetos a crear.
Abstract Factory
Data Access Object
El acceso a los datos varía dependiendo de la
fuente de los datos. El acceso al
almacenamiento persistente, como una base
de datos, varía en gran medida dependiendo
del tipo de almacenamiento (bases de datos
relacionales, bases de datos orientadas a
objetos, ficheros planos, etc.) y de la
implementación del vendedor.
Utilizar un Data Access Object (DAO) para
abstraer y encapsular todos los accesos a la
fuente de datos. El DAO maneja la conexión
con la fuente de datos para obtener y
almacenar datos.
Data Access Object
Data Access Object -
Participantes
 El BusinessObject representa los datos del cliente. Es el objeto que
requiere el acceso a la fuente de datos para obtener y almacenar datos.
Podríamos implementar un BusinessObject como un bean de sesión, un
bean de entidad o cualquier otro objeto Java, además de como un Servlet o
como un bean de apoyo.
 El DataAccessObject es el objeto principal de este patrón.
DataAccessObject abstrae la implementación del acceso a datos
subyacente al BusinessObject para permitirle un acceso transparente a la
fuente de datos. El BusinessObject también delega las operaciones de
carga y almacenamiento en el DataAccessObject.
 El DataSource representa la implementación de la fuente de datos. Una
fuente de datos podría ser una base de datos como un RDBMS, un
OODBMS, un repositorio XML, un fichero plano, etc. También lo pueden ser
otros sitemas (mainframes/legales), servicios (servicio B2B u oficina de
tarjetas de crédito), o algún tipo de repositorio (LDAP).
 El TransferObject representa un Transfer Object utilizado para el
transporte de datos. DataAccessObject podría utilizar un Transfer Object
para devolver los datos al cliente. El DataAccessObject también podría
recibir datos desde el cliente en un Transfer Object para actualizar los datos
Refinamiento del Patrón
Data Access Object
ADO.NET 2.0 y el Modelo
Independiente del
Proveedor
El modelo de programación del
modelo independiente del
proveedor se basa en el uso
del
patrón de diseño Factory y
proporciona una única API
para
tener acceso a las bases de
datos de varios proveedores.
Uniformidad al recorrer colecciones
Iterator
El patrón Iterator nos proporciona una manera
de acceder a los elementos de un objeto
agregado de manera secuencial sin exponer
su representación subyacente. De tal manera
es independiente el tipo de agregado que
exista o la manera en que almacena sus
elementos.
Iterator
Iterator - Participantes
Iterator  (AbstractIterator) define una
interfaz para acceder y recorrer los
elementos.
ConcreteIterator  (Iterator) implementa la
interfaz Iterator. Mantiene la posición actual
del recorrido por el Aggregate.
Aggregate  (AbstractCollection) define
una interfaz para la creación de un objeto
Iterator.
ConcreteAggregate  (Collection)
implementa la interfaz de creación de
Transparencia para el manejo de jerarquías
Composite
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.

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.
Composite
Composite
 Component   (DrawingElement) Declara las interfaces
para los objetos en la composición. Implementa el
comportamiento predeterminado para la interfaz común a
todas las clases, según sea necesario. Declara una interfaz
para acceder y administrar los componentes hijos.
Optionalmente define una interfaz para acceder al padre del
componente en la estructura recursiva, y la implementa si
es necesario.
 Leaf   (PrimitiveElement) Representa los objetos simples
en la composición . Un leaf no tiene hijos. Define el
comportamiento para los objetos primitivos en la
composición.
 Composite   (CompositeElement) Defines el
comportamiento para los elementos que tienen hijos.
Almacena los componentes hijos. Implementa operaciones
relacionadas con los hijos en la interfaz Component.
 Client  (CompositeApp) Manipula los objetos de la
composición a través de la interfaz Component.
Desacoplamiento entre datos y presentación
Model-View-Controller
Model-View-Controller (MVC) es un patrón
de arquitectura de software que separa los
datos de una aplicación, la interfaz de usuario,
y la lógica de control en tres componentes
distintos. El patrón MVC se ve frecuentemente
en aplicaciones web, donde la vista es la
página HTML, el control es el código que
provee de datos dinámicos a la página, y el
modelo contiene clases representativas de la
aplicación (como el mensaje de un foro, un
miembro registrado, etc.)
 Model-View-Controller
 MVC = diseño sofisticado y flexible para las GUIs

(MVC)
 Especifica una arquitectura de GUI amplia y de alto nivel
 Los detalles exactos varían dependiendo del arquitecto y del
dominio del problema
 Es uno de los patrones de diseño reconocidos más tempranamente

Procesa la entrada del usuario y

Controller actualiza el View y el Model de
manera adecuada

View Model

View Model

Negocios
(datos)
 Patrones de Diseño
Subyacentes
El patrón MVC está conformado por la combinación de un
conjunto de patrones, entre los cuales encontramos:
 Observer: desacopla los objetos mediante un sistema de
notificaciones
 Command: encapsula las operaciones como objetos
 Adapter: adapta los objetos existentes a nuevas situaciones
 Strategy: desacopla algoritmos con respecto a sus clientes
 Composite: trata a un conjunto de objetos como a uno solo
 Decorator: asigna de manera dinámica un comportamiento a un
objeto
 Factory: desacopla la creación de los objetos con respecto a sus
consumidores
Se puede optar por implementar tantos o tan pocos como se desee
Suscripciones y notificaciones
El patrón Observer
Basado en un sujeto y sus observadores
 También conocido como el patrón publisher-subscriber
 Es el mecanismo detrás del manejo de eventos de .NET

Click en un
botón!

Sujeto

delegado
Observador

delegado
Observador

delegado
Observador
 Objetivo de este Patrón de
Diseño
Acoplamiento débil entre el sujeto y el observador
 ¿Por qué? Para facilitar futuros cambios o reemplazos
Ejemplo:
 La vista y el controlador deberían saber muy poco el uno
del otro

delegado Controller

delegado
View
Representación de órdenes como objetos
El patrón Command
Representa a los comandos de IU como
objetos:
Public Class UIControl

Public Sub Lookup(...)

.
.
.
End Sub

Command
Sub Execute( )
…
End Sub
 Objetivo de este Patrón de
Diseño
Fomenta aún más el desacoplamiento de los
componentes
 Conforma una nueva capa abstracción

Provee un framework para soportar el

comportamiento dinámico:
 Nos permite crear IUs sensibles al entorno
intercambiando los objetos Command
 Agregar estado a los objetos Command para soportar
operaciones de Deshacer y Rehacer
Flexibilidad entre clases no compatibles
 ¡Advertencia!
Hay que tener un poco más de sutileza para
implementar este patrón
 Para hacerlo correctamente, se necesita aplicar además
el patrón Adapter
Public Class UIControl
Command
Public Sub SomeHandler(...)
Sub Execute( ) .
… .
Adapter End Sub .
End Sub

delegado
Lo que hemos aprendido…
r.masabel.a@hotmail.com