Hernan Dario Buitrago Morales - 624652
Diego Alejandro Castellanos H - 624680
Gracias por su atencion!
Patrones MCV, DAO, Observer, Memento
Patrones de Diseño
MVC
"Los patrones de diseño son el esqueleto de las soluciones a problemas comunes de sesarrollo de software"
Memento
Modelo Vista Controlador
Base para la búsqueda de soluciones a problemas comunesen el desarrollo de software
En general los patrones contienen
4 elementos esenciales:
- Nombre
- Problema
- Solucion
- Consecuencias
Patrón de diseño cuyo objetivo es organizar el flujo de datos en las aplicaciones permitiendo construir sistemas mas robustos y faciles de extender.
Es un patrón de diseño de software, y está catalogado como un patrón de comportamiento.
Se utiliza para guardar el estado de un objeto y poder luego restaurar el objeto a un estado previo.
Solucion
Problema
- El modelo representa la funcionalidad y los datos esenciales, y es independiente de la representacion de la interfaz.
- Cada vista tiene asociado un controlador, que recibe eventos y los traduce a solicitud de servicios.
- La vista obtiene datos del modelo y las despliega para el usuario.
- Las interfaces de usuario son cambiadas con frecuencia
- Diferentes paradigmas de interfaz. (Digitar informacion, mover botones...)
- Cambios en la funcionalidad se reflejan en la interfaz
Ventajas:
Componentes
- La aplicacion esta implementada modularmente.
- Sus vistas muestran informacion actualizada siempre.
- Las modificaciones a las vistas no afectan a los otros modulos de la aplicacion.
- Utilizada para construir grandes aplicaciones
- Se facilita la depuracion de errores
- Favorece la reutilizacion de codigo
- Facilita el mantenimiento
- Las vistas proveen mayor flexibilidad y agilidad
Vista:
Desventajas:
Da una presentacion del modelo. Generalmente esta obtiene los datos y estados que necesita mostrar desde el modelo. Es la interfaz que ve el usuario.
- El tiempo de desarrollo es grande.
- Es un patron orientado a objetos por lo que su implementacion es muy costosa y dificil en lenguaje que no utiliza este paradigma.
Es responsable de:
- Recibir datos del modelo y los muestra al usuario.
- Tiene un registro de su controlador asociado.
Contiene todos los datos, estados y logica de la aplicacion (Reglas del negocio).
Modelo:
Diagrama de Secuencia:
Es responsable de:
- Acceder a la capa de almacnamiento de datos.
- Define las reglas del negocio.
- Lleva un registro de las vistas y contoladores del sistema
Analogía:
Relación con otros patrones
Solución
Problema
Controlador:
Toma las entradas del usuario, entiende y gestiona lo que deben hacer en el modelo.
Guardar una "Instantánea" del estado de un objeto, de forma que pueda ser devuelto a su estado original sin revelar su contenido al resto del mundo.
- Se quiere poder restaurar el sistema desde estados pasados.
- Se desea facilitar el hacer y deshacer de determinadas operaciones.
Es responsable de:
- Recibe los eventos de entrada.
- Contiene las reglas de gestion de eventos (SI evento Z, entonces accion W)
Implementación
Ventajas:
Guardar temporalmente la perspectiva de una venta.
- Preservación de los límites de la encapsulación.
- Definición de interfaces reducidas y amplias.
Desventajas:
- El uso de mementos puede ser costoso, es costoso crear los objetos memento si se tiene que almacenar todas las partes del estado del originator.
- El uso frecuente de Mementos para almacenar estados internos de gran tamaño, podría resultar costoso y perjudicar el rendimiento del sistema.
Estructura:
Implementación
Colaboraciones
Implementación
Un conserje solicita un memento a un creador, lo almacena durante un tiempo y se lo devuelve a su creador
Descripción:
Memento
Guarda el estado interno del objeto Creador. El memento puede guardar tanta información del estado interno del creador como sea necesario a discreción del creador.
Protege frente a accesos de otros objetos que no sean el creador.
Creador
Crea un memento que contiene una instantánea de su estado interno actual.
Conserje
Es responsable de guardar en lugar seguro el memento.
Bibliografia:
Head First - Design Patterns. Eric Freeman & Elisabeth Freeman - O'Reilly
Design Patterns. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides - Addison Wesley. 2008
http://www.slideshare.net/An3s/patron-memento
http://jms32.eresmas.net/web2008/documentos/informatica/documentacion/logica/patrones/memento/2008_08_12_MementoDescripcion.html#Refh2_Proposito
Aprende rápido mi perro!!
DAO
Observer
Data Access Object
Es un método muy simple, el cual se trata de mapear objetos a bases de datos. Para generar un patrón DAO, un desarrollador podría escribir una clase que contiene un atributo para cada campo en la tabla clientes.
Este patron define una relacion uno a muchos, entre un grupo de objetos.
Cuando un objeto cambia su estado, todos sus dependientes son notificados y actualizados automaticamente.
Relación con otros patrones
- Data Transfer Object(DTO).
- Factory
Solución
Problema
- Suministra una interfaz común entre la aplicación y uno o más repositorios de datos.
- Soluciona el problema del diferencial de impedancia.
- Administra las conexiones con la fuente de datos, recupera y almacena información en la fuente de datos.
- La necesidad de acceso a datos de una manera fácil.
- Diferentes API's para el acceso a mecanismos
- Dependencia de código (Difícil mantenimiento)
Implementación
En primer lugar, debemos hacer las clases que representan nuestros datos.
Ventajas:
- Centralizar el control de acceso a datos.
- Transparencias en el acceso a datos.
- Organiza todos los accesos a datos en una capa separada.
Desventajas:
- Necesita crearse una jerarquía de clases
- Aumenta la complejidad del diseño inicial
Descripcion:
Colaboraciones:
Implementación
Luego hacemos una interface. Esta interface tiene que tener los métodos necesarios para obtener y almacenar Personas.
- Los objetos claves son "Subject" y "Observer".
- La motivacion de este patron es la reutilizacion.
- Puede no haber relacion directa entre objetos.
- El tipo de interaccion es conocida como Publicar-Suscribir.
- El Subject es el publicador de notificaciones.
- Cualquier numero de Observers pueden suscribirse para recibir notificaciones.
Aplicabilidad:
Consecuencias:
Beneficios y Obligaciones
Estructura:
- Cuando una abstraccion tiene 2 aspectos o mas, uno dependiente del otro.
- Cuando un objeto requiere el cambio de otros, y no se sabe cuantos objetos necesitan ser cambiados.
- Cuando un objeto debe notificar a otros objetos sin estimar cuantos son estos.
- Acoplamiento abstracto entre Subject y Observer.
- Soporte para la comunicacion difundida.
- Actualizaciones Inesperadas
Implementación
Se hace la implementación de la InterfaceDAO, ya contra una base de datos concreta o usando una herramienta iBATIS, Hibernate, etc., determinada.
Descripción:
BusinessObject: Representa los datos del cliente.
DataAccessObject: El DataAccessObject es el objeto principal de este patrón.
Implementacion:
Estructura:
Participantes:
Analogia:
Data Source: Esto representa una aplicación de origen de datos.
TransferObject: Esto representa una transferencia de objetos utilizados como soporte de datos.
- Conoce sus Observers. Cualquier numero de observers pueden observar a Subject.
- Provee una interfaz para adjuntar y separar objetos Observer.
1. Asignacion del Subject a los Observers
2. Observar mas de un Subject
3. Quien realiza la actualizacion?
4. Referencias flotantes a subjects eliminados
5. El estado del subject es seguro?
6. Evitar los protocolos especificos de actualizacion del Observer
7. Especificar explicitamente las modificaciones de interes
8. Encapsular contexto, actualizar semantica
9. Combinar las clases Subject y Object
- Define una interfaz de actualizacion para los objetos Observer que deben ser notificados de los cambios en el Subject.
- Almacena estados de interes para los objetos ConcreteObserver.
- Envia una notificacion a sus Observers cuando el estado cambia
- Mantiene referencia de objetos ConcreteSubject.
- Almacena los estados que deben ser consistentes con los Subject.
- Implementa la actualizacion del Observer.
Patrones relacionados: