Patrones de diseño de GoF

Patrones de
Diseño
Octubre de 2012
Profesora: Yaskelly Yedra
Ingeniería de Software

Introducció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.

Patró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

PatróndeDiseñ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
CategoríadePatrones
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ónPatronesInvolucrados
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ónPatronesInvolucrados
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

Singleton
IntenciónMotivació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.

Singleton
AplicabilidadEstructura
 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.

Singleton
Participantes
Colaboraciones
Consecuencias
 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.

Singleton
Implementación

Patrones EstructuralesCategoríadePatrones
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 EstructuralesPatronesInvolucrados
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.

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.

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.

Facade
Intenció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.
Motivació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.

Facade
Motivación

Patrones EstructuralesAplicabilidadEstructura
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.

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.

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 facade
abstracta, 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++.

Ejemplo: Una fachada para un sistema de compilación
Facade

Facade
Ejemplo: Una fachada para un sistema de compilación

Facade
Ejemplo: Una fachada
para un sistema de
compilación

Patrones de ComportamientoCategoríadePatrones
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 ComportamientoPatronesInvolucrados
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.

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.

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.

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.

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.

Observer
IntenciónMotivació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.

Observer
Motivación

Observer
AplicabilidadEstructura
 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).

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

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 ConcreteObserver
puede pedir al Subject más información.
Observer

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

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

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

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

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

Implementación
Observer

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
Subject
MVC en entornos web (J2EE)
 Model=EJB
 View=JSP
 Controller=servlet

Conclusiones
Diseño
de Patrón Patrones
GoF
De
Creación
De
Comportamiento
Patrones
Estructurales

Conclusiones
 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.

Bibliografía
 “Design patterns, elements of reusable object
oriented software”. Gamma, Helm, Jonhnson,
Vlissides. Addison Wesley, 1995 (traducido al
español en 2003).

Patrones de diseño de GoF

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Patrones de diseño de GoF

Similar a Patrones de diseño de GoF (20)

Más de Yaskelly Yedra

Más de Yaskelly Yedra (20)

Patrones de diseño de GoF