patrones de diseño de gof
TRANSCRIPT
Intr
od
ucc
ión
Son diseñados para un problema en especifico, pero de forma general como para poder adecuarse a futuros requisitos y problemas.
Evitan el rediseño en la medida de lo posible. Evitan resolver cada problema partiendo de cero. Reutilizan soluciones que han sido útiles en el
pasado. Patrones recurrentes de clases y comunicación
entre objetos en muchas soluciones de diseño.
Pat
rón
Un esquema que se usa para solucionar un problema.
El esquema ha sido probado extensivamente, y ha funcionado. Se tiene experiencia sobre su uso.
Existen en muchos dominios: Novelas y el cine: “héroe trágico”, “comedia
romántica”, etc. Arte. Ingenierías. Arquitectura.
• Christopher Alexander. “A Pattern Language: Towns, Buildings, Construction”. 1977.
• http://www.patternlanguage.com
Pat
rón
de
Dis
eñ
o
Reutiliza diseños abstractos que no incluyen detalles de la implementación.
Un patrón es una descripción del problema y la esencia de su solución, que se puede reutilizar en casos distintos.
Es una solución adecuada a un problema común.Asociado a orientación a objetos, pero el principio
general es aplicable a todos los enfoques de diseño software.
Intención
Motivación
Aplicabilidad (usar el patrón cuando)
Estructura
Participantes
Colaboraciones
Consecuencias
Implementación (factores a tener en cuenta)
Estructura de un Patrón GoF
Patrones de Creación
Patrones Estructurales
Patrones de Comportamiento
Cat
ego
ría
de
Pat
ron
es
Cómo se comunican los objetos, cooperan y distribuyen las responsabilidades para lograr
sus objetivos.
Composición de objetos.
Implica el proceso de instanciar objetos.
Patrones de CreaciónP
atro
ne
s In
volu
crad
os
1. Prototype o Prototipo
2. Singleton o Instacia única
Especifica los tipos de objetos a crear por medio de una instancia prototípica, y crea nuevos objetos copiando este prototipo.
Garantiza que una clase solo tenga una instancia y proporciona un punto de acceso global a la misma.
Patrones de CreaciónP
atro
ne
s In
volu
crad
os
4. Abstract Factory o Fábrica abstracta
5. Builder o Constructor
Proporciona una interfaz para crear familias de objetos relacionados sin especificar sus clases concretas.
Separa la construcción de un objeto complejo de su representación.
Define una interfaz para crear un objeto, pero deja que sean las subclases las que decidan que clase instanciar.
3. Factory Method o Método de fabricación
Patrones de CreaciónSingleton
Inte
nci
ón
Mo
tiva
ció
n
Asegurar que una clase tiene una única instancia y proporciona un punto de acceso global a dicha instancia
Hay veces que es importante asegurar que una clase tenga una sola instancia, por ejemplo: Un gestor de ventanas Una única cola de impresión Un único sistema de ficheros Un único fichero de log, o un único repositorio.
¿Cómo asegurarlo? una variable global hace el objeto accesible, pero se puede instanciar varias veces.
Responsabilidad de la clase misma: actuar sobre el mensaje de creación de instancias.
Patrones de CreaciónSingleton
Ap
licab
ilid
adEs
tru
ctu
ra
Cuando debe haber una sola instancia, y debe ser accesible a los clientes desde un punto de acceso conocido.
Cuando la única instancia debe ser extensible mediante subclasificación, y los clientes deben ser capaces de usar una instancia extendida sin modificar su código.
Patrones de CreaciónSingleton
Particip
ante
s
Colaboraciones
Co
nse
cue
nci
as
Acceso controlado a la única instancia. Espacio de nombre reducido. Mejora sobre el uso de variables
globales. Permite el refinamiento de operaciones y la representación. Se puede
subclasificar de la clase Singleton y configurar la aplicación con una instancia de esta clase.
Fácil modificación para permitir un número variable de instancias. Más flexible que las operaciones de clase.
Los clientes acceden a la instancia de un Singleton a través de la operación “Instance”.
Define una operación de clase, llamada “Instance” que deja a los clientes acceder a la única instancia.
Puede ser responsable de crear su única instancia.
Patrones EstructuralesC
ate
gorí
a d
e P
atro
ne
s Establecen cómo se componen clases y objetos para formar estructuras mayores que implementan nueva funcionalidad.
Los patrones de clase usan la herencia para componer interfaces o implementaciones (ej.: Adapter).
Los patrones de objeto, describen maneras de componer objetos para implementar nueva funcionalidad. Flexibilidad, ya que se puede cambiar la
configuración en tiempo de ejecución.
Patrones EstructuralesP
atro
ne
s In
volu
crad
os
6. Composite o Composición
Combina objetos en estructuras de árboles para representar jerarquías de parte-todo.
7. Proxy
Proporciona un sustituto o representante de otro objeto para controlar el acceso a este.
8. Decorator o Decorador
Añade dinámicamente nuevas responsabilidades a un objeto. Alternativa de la herencia.
Patrones EstructuralesP
atro
ne
s In
volu
crad
os
9. Facade o Fachada
10. Bridge o Puente
Proporciona una interfaz unificada para un conjunto de interfaces de un subsistema.
Desacopla una abstracción de su implementación, de manera que puedan variar de forma independiente.
Patrones EstructuralesP
atro
ne
s In
volu
crad
os
11. Adapter o Adaptador
12. Flyweight o Objeto Ligero
Convierte la interfaz de una clase en otra distinta, que es la que esperan los clientes.
Usa el compartimiento para permitir un gran número de objetos de grano fino de forma eficiente.
Patrones EstructuralesFacade
Inte
nci
ón 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.
Mo
tiva
ció
n
Estructurar un sistema en subsistemas ayuda a reducir su complejidad.
Un objetivo típico de diseño es minimizar la comunicación y dependencias entre subsistemas.
Un modo de conseguir esto es introducir un objeto fachada que proporcione una interfaz única y simplificada a los servicios más generales del subsistema.
Patrones EstructuralesA
plic
abili
dad
Estr
uct
ura
Facade
Queramos proporcionar una interfaz simple a un subsistema complejo.
Sólo los clientes que necesitan más personalización necesitarán ir más allá de la fachada.
Haya muchas dependencias entre los clientes y las clases que implementan una abstracción. La fachada desacopla el subsistema de sus clientes y otros subsistemas (mejora acoplamiento y portabilidad).
Queramos dividir en capas nuestros subsistemas. La fachada es el punto de entrada a cada subsistema.
Patrones Estructurales
Participantes
Observaciones
Facade
Facade (Compiler). Sabe qué clases del subsistema son las responsables ante una petición. Delega las peticiones de los clientes en los objetos apropiados del
subsistema.
Clases del Subsistema (Scanner, Parser, ProgramNodeBuilder, CodeGenerator). Implementan la funcionalidad del subsistema. Realizan las labores encomendadas por el objeto Facade. No tienen referencias al objeto Facade.
Los clientes se comunican en el sistema enviando peticiones al objeto Facade, que las reenvía a los objetos apropiados.
Los clientes que usan la fachada no tienen que acceder directamente a los objetos del subsistema.
Patrones Estructurales
Consecuencias
Facade
Oculta a los clientes los componentes del sistema, haciendo el sistema más fácil de usar.
Promueve acoplamiento débil entre el subsistema y sus clientes. Elimina dependencias y puede reducir el tiempo de compilación.
No impide que las aplicaciones usen las clases del subsistema en caso necesario.
Implementación
Reducción del acoplamiento cliente-subsistema. Clase facadeabstracta, con clases concretas para las diferentes implementaciones de un subsistema.
Clases del subsistema públicas o privadas Uso de espacios privadas. de nombres en C++.
Patrones de ComportamientoC
ate
gorí
a d
e P
atro
ne
s Tratan sobre algoritmos y la asignación de responsabilidades entre objetos.
Describen no sólo patrones de clases y objetos, sino patrones de comunicación entre ellos.
Caracterizan un flujo de control complejo, difícil de seguir en tiempo de ejecución.
Permiten que el diseñador se concentre sólo en cómo interconectar objetos.
Patrones de ComportamientoP
atro
ne
s In
volu
crad
os
13. Chain of Responsability o Cadena de Responsabilidad
14. State o Estado
Permite que un objeto modifique su comportamiento cada vez que cambia su estado interno.
Evita acoplar el emisor de una petición a su receptor, al dar a más de un objeto la posibilidad de responder a la petición.
Patrones de ComportamientoP
atro
ne
s In
volu
crad
os
15. Observer o Observador
16. Iterator o Iterador
Proporciona un modo de acceder secuencialmente a los elementos de un objeto agregado sin exponer su representación interna
Define una dependencia de uno a muchos entre objetos, de forma que cuando un objeto cambia de estado, se notifican y se actualizan automáticamente todos los objetos que dependen de él.
Patrones de ComportamientoP
atro
ne
s In
volu
crad
os
17. Template Method o Plantilla
18. Visitor o Visitante
Define en una operación el esqueleto de un algoritmo delegando en las subclases algunos de sus pasos.
Representa una operación sobre los elementos de una estructura de objetos. Permite definir una nueva operación sin cambiar las clases de los elementos sobre los que opera.
Patrones de ComportamientoP
atro
ne
s In
volu
crad
os
20. Memento o Recuerdo
Representa y externaliza el estado interno de un objeto sin violar su encapsulación
19. Command o Comando
Encapsula una petición en un objeto, permitiendo así entre otras cosas parametrizar a los clientes con distintas peticiones, encolar o llevar un registro de las mismas.
21. Strategy o Estrategia
Define una familia de algoritmos, encapsula cada uno de ellos y los hace intercambiables.
Patrones de ComportamientoP
atro
ne
s In
volu
crad
os
23. Interpreter
22. Mediator o Mediador
Define un objeto que encapsula cómo interactúan un conjunto de objetos.
Dado un lenguaje, define una representación de su gramática junto con un intérprete que usa dicha representación para interpretar las sentencias del lenguaje.
Patrones de ComportamientoObserver
Inte
nci
ón
Mo
tiva
ció
n Mantener consistencia entre objetos relacionados.No queremos obtener dicha consistencia aumentando el
acoplamiento entre clases.Ej.: separación de la presentación en GUI de los datos de
aplicación subyacente.
Dependents Publish-Subscribe
También conocido como
Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambie de estado se notifique y actualicen automáticamente todos los objetos que dependen de él.
Patrones de ComportamientoObserver
Ap
licab
ilid
adEs
tru
ctu
ra
Cuando una abstracción tiene dos aspectos y uno depende del otro. Cuando un cambio en un objeto requiere cambiar otros, y no sabemos
cuántos hay que cambiar. Cuando un objeto debería ser capaz de notificar a otros sin hacer
suposiciones sobre quiénes son dichos objetos (esto es, no queremos que los objetos estén fuertemente acoplados).
Patrones de Comportamiento
Participantes
Subject. Conoce a sus observadores, que pueden ser un número arbitrario. Proporciona un interfaz para añadir y quitar objetos Observer.
Observer. Define un interfaz de actualización para los objetos que deben ser
notificados sobre cambios en un sujeto. ConcreteSubject.
Almacena estado de interés para ConcreteObservers. Manda notificaciones a sus observadores cuando su estado cambia.
ConcreteObserver. Mantiene una referencia a objetos ConcreteSubject. Almacena el estado que debe ser consistente con el del sujeto. Implementa el interfaz de actualización del Observer para mantener su
estado consistente con el del sujeto.
Observer
Patrones de Comportamiento
Colaboraciones
El ConcreteSubject notifica a sus observadores cada vez que se produce un cambio que pudiera hacer que el estado de estos fuese inconsistente con el suyo.
Después de ser notificado del cambio, un ConcreteObserverpuede pedir al Subject más información.
Observer
Patrones de Comportamiento
Consecuencias
Permite modificar los sujetos y observadores de manera independiente.
Se pueden reutilizar los sujetos sin sus observadores y viceversa. Se pueden añadir observadores sin modificar el sujeto u otros
observadores. Acoplamiento abstracto entre sujeto y observador. El sujeto no
conoce la clase concreta de ningún observador (el acoplamiento es mínimo).
Capacidad de comunicación mediante difusión. La notificación del sujeto se envía automáticamente a todos los observadores suscritos. Se pueden añadir y quitar observadores en cualquier momento.
Actualizaciones inesperadas. Una operación aparentemente inofensiva sobre el sujeto puede desencadenar una cascada de cambios en los observadores.
Observer
Patrones de Comportamiento
Implementación
Correspondencia entre sujetos y observadores. Que el sujeto guarde referencias a los observadores a los que debe notificar.
Observar más de un sujeto. Ej.: una hoja de cálculo puede observar más de un origen de datos. Extender la interfaz de actualización para que el observador sepa qué sujeto
se ha actualizado (quizá simplemente el sujeto se pase a sí mismo como parámetro del update()).
¿Quién dispara la actualización? Las operaciones que cambien el estado del sujeto llaman a Notify().
• Ventaja: los clientes no tienen que hacer nada.• Inconveniente: no es óptimo si hay varios cambios de estado seguidos.
Los clientes llaman a Notify():• Ventaja: se puede optimizar llamando a notify sólo después de varios• cambios.• Inconveniente: los clientes tienen la responsabilidad añadida de llamar• a Notify().
Observer
Patrones de Comportamiento
Implementación
Referencias perdidas a sujetos borrados. Una manera de evitarlo es notificar a los observadores cuando se
borra un sujeto.
Asegurarse de que el estado del Sujeto sea consistente consigo mismo antes de la notificación: Hay que tener cuidado con las operaciones heredadas.
Observer
Patrones de Comportamiento
Implementación
Evitar protocolos específicos del obervador: los modelos push y pull. Las implementaciones de observer suelen hacer que el sujeto envíe
información adicional como parámetro de Update(). Dos extremos:
• Modelo Push: el sujeto envía información detalla del cambio, quieran los observadores o no.
Inconveniente: observadores menos reutilizables.• Modelo Pull: el sujeto no envía nada, y los observadores piden
después los detalles explícitamente.Inconveniente: puede ser poco eficiente.
Especificar las modificaciones de interés explícitamente: Mejorar la eficiencia haciendo que los observadores registren solo
aquellos eventos que les interesen. Los observadores se subscriben a aspectos del sujeto.
Observer
Patrones de Comportamiento
Implementación
Encapsular la semántica de las operaciones complejas. Si la relación de dependencia entre sujetos y
observadores es compleja, puede ser necesario un objeto intermedio para la gestión de cambios (ChangeManager).
Minimizar el trabajo necesario para que los observadores reflejen los cambios en el sujeto.
Ej.: si varios sujetos han de cambiarse, asegurarse de que se notifique a los observadores sólo después del cambio en el último sujeto.
Observer
Patrones de Comportamiento
Usos conocidos
Observer
Sistemas de eventos en Java (observer=listener) AWT/Swing Javabeans
MVC en el sistema de ventanas de Smalltalk Model=Subject View=Observer Controller=Cualquier objeto que cambie el estado de
SubjectMVC en entornos web (J2EE)
Model=EJB View=JSP Controller=servlet
Co
ncl
usi
on
es
Los patrones ayudan a generar software “maleable” (software que soporta y facilita el cambio, la reutilización y la mejora).
Cada patrón describe la solución a problemas que se repiten una y otra vez en nuestro entorno, de forma que se puede usar esa solución todas las veces que haga falta.
Los patrones de diseño capturan el conocimiento que tienen los expertos a la hora de diseñar.
Los patrones de diseño son guías, no reglas rigurosas.