Este documento presenta una introducción a los patrones de diseño de software conocidos como patrones GOF. Explica brevemente qué es un patrón de diseño y clasifica los patrones GOF en tres categorías: patrones de creación, estructura y comportamiento. Luego describe algunos patrones específicos como Factory Method, Observer y Strategy. Finalmente incluye una bibliografía sobre el libro original de los patrones GOF.

1. Patrones GOF
Joan Sebastián Ramírez Pérez
2016

2. Agenda
• ¿Qué es un patrón de diseño?
• Patrones GOF
• Patrones de creación
• Patrones de estructura
• Patrones de comportamiento
• Bibliografía

3. ¿Qué es un patrón de software?

4. 1977, A Pattern Language, Christopher Alexander
“Cada patrón describe un problema que
ocurre una y otra vez en nuestro medio
ambiente y, a continuación describe el núcleo
de la solución a ese problema, de tal manera
que se puede utilizar esta solución un millón
de veces, sin tener que hacerlo de la misma
manera dos veces”

5. ¿Qué es un patrón de software?
• Solución probada a un problema recurrente.
• Solución reutilizable a un problema común en un
contexto dado.

6. Patrones GOF

7. Patrones GOF
Gang of Four:
• Ralph Johnson
• Erich Gamma
• Richard Helm
• John Vlissides

8. Clasificación de los patrones GOF
• Propósito
• Refleja lo que hace un patrón
• Se divide en Patrones de Creación , Estructura y
Comportamiento
• Alcance
• Especifica si el patrón se aplica principalmente a clases
u objetos

9. Clasificación patrones GOF

10. Patrones de creación

11. Patrones de creación
• Factory Method: crea una instancia de varias clases
derivadas
• Abstract Factory: crea una instancia de varias familias de
clases
• Builder
Separa la construcción de un objeto de su representación
• Prototype: genera una instancia y la inicializa, que puede ser
copiada o colgada.
• Singleton: una clase de la cual solo puede existir una única
instancia

12. Factory Method
• Problema: una clase no puede anticipar la clase de
objetos que debe crear. Una clase quiere sus
subclases especifiquen los objetos que crean.
• Contexto: los frameworks utilizan clases abstractas
para definir y mantener las relaciones entre objetos.
Una responsabilidad es crear tales objetos.
• Solución: definir una interfaz para crear un objeto, pero
dejando la elección de su tipo a las subclases, la
creación se aplaza hasta el tiempo de ejecución.

13. Factory Method Patrones de creación

14. Participantes Factory Method
• Product: define la interfaz para los objetos que
FactoryMethod crea.
• ConcreteProduct: implementa la interfaz Product.
• Creator(o Factory): declara el método FactoryMethod,
que devuelve un objeto Producto. Puede llamar al
método de generación para la creación de objetos
Product
• ConcreteCreator: sobre-escribe el método de
generación para crear objetos ConcreteProduct.

15. Abstract Factory
• Problema: se desea proporcionar una biblioteca de
clases de productos. También se quiere revelar sólo
sus interfaces, no sus implementaciones.
• Contexto: evitar añadir código a las clases existentes
con el fin de hacer que encapsule información más
general.
• Solución: proporcionar una interfaz para crear familias
de objetos relacionados o dependientes sin especificar
sus clases concretas.

16. Abstract Factory Patrones de creación

17. Participantes Abstract Factory
• AbstractFactory: declara una interfaz para las operaciones que
crean AbstractProduct.
• ConcreteFactory: implementa operaciones para crear Product
concretos.
• AbstractProduct: declara una interfaz para un tipo de objetos
Product.
• Product: define un producto a ser creado por el ConcreteFactory
correspondiente; que implementa la interfaz AbstractProduct.
• Client: utiliza las interfaces declaradas por las clases
AbstractFactory y AbstractProduct.

18. Builder
• Problema: cuanto más complejo es una aplicación, la
complejidad de las clases y los objetos que utiliza
aumenta.
• Contexto: una aplicación necesitar un mecanismo para
la creación de objetos complejos que es independiente
de los que componen el objeto.
• Solución: define una instancia para la creación de un
objeto dejando que las subclases decidan qué clase
instanciar.

19. Builder Patrones de creación

20. Participantes Builder
• Builder: especifica una interfaz abstracta para crear
partes de un objeto de Product.
• ConcreteBuilder: construye une las partes del producto
mediante la implementación de la interfaz Builder.
• Director: construye el objeto complejo mediante la
interfaz Builder.
• Product: representa el objeto complejo que se está
construyendo.

21. Singleton
• Asegura que una clase tiene una única instancia y
proveer un punto de acceso global a ella.
• Inicialización "just-in-time" o inicialización "on first use"
encapsulada.

22. Singleton Patrones de creación

23. Patrones de estructura

24. Patrones de estructura
• Adapter: relaciona interfaces de diferentes clases.
• Bridge: separa la interfaz de un objeto de su implementación.
• Composite: una estructura de árbol de objetos simples y
compuestos.
• Decorator: añadir responsabilidades a los objetos
dinámicamente.
• Facade: una única clase que representa todo un subsistema.
• Flyweight: una instancia usada para compartir de manera
eficiente.
• Proxy: un objeto que representa a otro objeto.

25. Adapter
• Problema: se desea utilizar una clase existente, y su
interfaz no coincide con la que necesita. Aplica de igual
modo cuando se quieren crear clases reutilizables que
cooperen con clases sin relación o imprevistas.
• Contexto: relacionar dos componentes que no tienen
una interfaz común.
• Solución: convertir la interfaz de una clase en otra
interfaz que el clientes espera.

26. Adapter Patrones de estructura

27. Participantes Adapter
• Target: define la interfaz de dominio específico que
utiliza Client.
• Adapter: adapta la interfaz Adaptee para la interfaz de
destino.
• Adaptee: define una interfaz existente que necesita
adaptarse.
• Client: colabora con objetos de acuerdo con la interfaz
Target.

28. Facade
• Problema: proveer una interfaz simple a un subsistema
complejo.
• Contexto: minimizar la comunicación y dependencias
entre subsistemas.
• Solución: proporcionar una interfaz unificada para un
conjunto de interfaces de un subsistema.

29. Facade Patrones de estructura

30. Participantes Facade
• Façade: conoce cuáles clases del subsistema son
responsables por una petición y delegan peticiones del
cliente a los objetos del subsistema apropiado.
• Clases del subsistema: Implementan una funcionalidad
del subsistema y llevan a cabo el trabajo asignado por
el objeto Façade.

31. Patrones de comportamiento

32. Command
• Problema: especificar, encolar y ejecutar peticiones en
diferentes tiempos. Aplica también para callbacks.
• Contexto: emisión de peticiones a objetos sin saber
nada de la operación que se solicite o el receptor de la
solicitud.
• Solución: encapsular una petición como un objeto y
almacenar las peticiones en una cola.

33. Command Patrones comportamiento

34. Participantes Command
• Command: declara una interfaz para ejecutar una
operación.
• ConcreteCommand: extiende de Command para
implementar el método ejecute al invocar las operaciones
correspondientes en el Receiver.
• Invoker: le pide al Command que ejecute la petición.
• Receiver: sabe cómo ejecutar las operaciones.
• Client: crea un objeto ConcreteCommand y le asigna su
Receiver.

35. Observer
• Problema: un cambio en un objeto requiere cambios en
otros,y no se sabe cuántos objetos necesitan ser
cambiados. Una abstracción tiene dos aspectos
dependientes.
• Contexto: al fragmentar un sistema en una colección de
clases cooperativas, se requiere mantener la
consistencia entre objetos relacionados.
• Solución: definir un dependencia uno-a-muchos entre
objetos, para que al cambiar un objeto, todos sus
dependientes sean notificados automáticamente.

36. Observer Patrones de comportamiento

37. Participantes Observer
• Observable: declara una interfaz para añadir o remover
Observers del cliente.
• ConcreteObservable: extiende Observable. Mantiene el
estado del objeto y cuando cambia, notifica a los
Observers ligados.
• Observer: interfaz que define las operaciones a ser
usadas para notificar a este objeto.
• ConcreteObserverA, ConcreteObserver2:
implementaciones concretas de Observer.

38. Strategy
• Problema: se requieren diferentes variantes de un
algoritmo.
• Contexto: clases relacionadas sólo difieren en su
comportamiento.
• Solución: define una familia de algoritmos, los
encapsula, y los hace intercambiables.

39. Strategy Patrones de comportamiento

40. Participantes Strategy
• Strategy: declara una interfaz para soportar todos los
algoritmos
• ConcreteStrategy: extiende a Strategy. Cada
ConcreteStrategy implementa un algoritmo.
• Context: mantiene una referencia al objeto Strategy y
define una interfaz para una interface que deja a
Strategy accesar sus datos.

41. Bibliografía

42. Bibliografía
• Gamma, Erich; Helm, Richard; Johnson, Ralph;
Vlissides, John(1995). Design Patterns: Elements of
Reusable Object-Oriented Software. Reading,
Massachusetts: Addison Wesley Longman, Inc.