Patrones GOFJoan Sebastián Ramírez Pérez2016

Agenda• ¿Qué es un patrón de diseño?

• Patrones GOF

• Patrones de creación

• Patrones de estructura

• Patrones de comportamiento

• Bibliografía

¿Qué es un patrón de software?

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”

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

Patrones GOF

Patrones GOFGang of Four:

• Ralph Johnson

• Erich Gamma

• Richard Helm

• John Vlissides

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

• Patrones de Clase y de Objeto

Clasificación patrones GOF

Patrones de creación

Patrones de creación• Factory Method: crea una instancia de varias clases

derivadas

• Abstract Factory: crea una instancia de varias familias de clases

• BuilderSepara 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

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.

Factory Method Patrones de creación

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.

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.

Abstract Factory Patrones de creación

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.

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.

Builder Patrones de creación

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.

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.

Singleton Patrones de creación

Patrones de estructura

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.

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.

Adapter Patrones de estructura

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.

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.

Facade Patrones de estructura

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.

Patrones de comportamiento

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.

Command Patrones comportamiento

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.

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.

Observer Patrones de comportamiento

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.

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.

Strategy Patrones de comportamiento

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.

Bibliografía

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.