patrones de diseño de gof

Patrones de Diseño

Octubre de 2012

Profesora: Yaskelly Yedra

Ingeniería de Software

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.


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.


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.


Implementación

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.


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.


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.


Motivación

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.


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


Ejemplo: Una fachada para un sistema de compilación

Facade


Ejemplo: Una fachada para un sistema de compilación

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.


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.


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.


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.


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.


Motivación


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


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 ConcreteObserverpuede 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

SubjectMVC en entornos web (J2EE)

Model=EJB View=JSP Controller=servlet

Co

ncl

usi

on

es

Diseño de Patrón Patrones

GoF

De Creación

De Comportamiento

Patrones

Estructurales

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.

Bib

liogr

afía

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