Patrones GOF
Descargar como PPTX, PDF2 recomendaciones5,503 vistas
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.
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
- 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
- 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.
- 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.
- 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.