Ricardo D. Masabel AvendañoMicrosoft Certified Professional

AgendaRepasoIteratorCompositeIntegración de la IU con Model-View-

ControllerObserverCommandAdapterResumen

Lo que vimos en la sesión anterior

Template MethodUsando 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.

FactoryEste 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.

+CreateObjectA()+CreateObjectB()+CreateObjectC()

Factory

Factory MethodFactory 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 MethodUsar 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 FactoryEl 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 ObjectEl 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 en la fuente de datos.

Refinamiento del PatrónData Access Object

ADO.NET 2.0 y el Modelo Independiente del ProveedorEl modelo de programación El modelo de programación

del del

modelo independiente delmodelo independiente del

proveedor se basa en el uso proveedor se basa en el uso deldel

patrón de diseño patrón de diseño FactoryFactory y y

proporciona una única API proporciona una única API parapara

tener acceso a las bases detener acceso a las bases de

datos de varios proveedores. datos de varios proveedores.

Uniformidad al recorrer colecciones

IteratorEl 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 - ParticipantesIterator  (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 Iterators para retornar una instancia del ConcreteIterator adecuado.

Transparencia para el manejo de jerarquías

CompositeEl 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

CompositeComponent   (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-ControllerModel-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)MVC = diseño sofisticado y flexible para las GUIs 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

Controller

View

View

Model

Model

Negocios(datos)

Procesa la entrada del usuario y actualiza el View y el Model de manera adecuada

Patrones de Diseño SubyacentesEl 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 ObserverBasado 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

Sujeto

Observador

Observador

Observador

delegado

delegado

delegado

Click en un botón!

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

Controller

View

delegado

delegado

Representación de órdenes como objetos

El patrón CommandRepresenta a los comandos de IU como objetos:

Public Class UIControl

Public Sub Lookup(...) . . . End Sub

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

Public Sub SomeHandler(...) . . . End Sub

Public Class UIControl

Public Sub SomeHandler(...) . . . End Sub

Command

Sub Execute( ) …End Sub

delegado

Adapter

Lo que hemos aprendido…

r.masabel.a@hotmail.com