Design pattern Ing. Darío Guillermo Cardacci Centro de Altos Estudios en Tecnología Informática Facultad de Tecnología Informática Universidad Abierta Interamericana. Montes de Oca 745. Capital Federal. Argentina. 4301-5240. 4301-5323. dario.cardacci@vaneduc.edu.ar Rosario – Argentina - 2007

¿Cómo capturar, representar, transmitir y reutilizar todo esto? Design pattern MOTIVACIÓN El diseño de software es naturalmente difícil, incluso utilizando buenas técnicas Diseñar la experiencia es valiosa Sin embargo ¿Cómo capturar, representar, transmitir y reutilizar todo esto?

Design pattern OTROS PROBLEMAS Rigidez Fragilidad Inmovilidad del código Flexibilidad Extensibilidad Complejidad

Design pattern ¿Cuál es la mejor solución? CUÁL ES LA MEJOR SOLUCIÓN ¿Implementar métodos concretos en sub clases concretas? ¿Delegar en clases menos especializadas dentro de una jerarquía (super clases)? ¿Componer o heredar? ¿Inversión de control o control directo? ¿Definir clases abstractas? ¿Definir algoritmos abstractos? ¿Cuál es la mejor solución?

Design pattern LOS HECHOS CONCRETOS Permanentemente adquirimos experiencia Dominio Problema No se transmite en forma ordenada Los expertos aprenden por ensayo y error Los expertos manejan un metalenguaje ad-hoc

Design pattern Christopher Alexander QUÉ ES UN PATRON "Un patrón describe un problema que ocurre una y otra vez en un contexto, así como la solución, de tal manera que se puede usar millones de veces más adelante sin tener que volver a pensarla otra vez " Christopher Alexander

QUIÉN FUE CHRISTOPHER ALEXANDER Design pattern QUIÉN FUE CHRISTOPHER ALEXANDER 1977. Publicó “A Pattern Language: Towns, Buildings, Construction”. 1979. Publicó “The Timeless Way of Building”.

Design pattern HITOS 1987. Ward Cunningham y Kent Beck publicaron un artículo en OOPSLA-87 (Object-Oriented Programming, Systems, Languages, and Applications) titulado “Using Pattern Languages for OO Programs”, 5 patrones HCI (interacción hombre-ordenador) 90's Erich Gamma, Richard Helm, Ralph Johnson y John Vlisides (GoF - Gang of Four) publicaron el libro “Design Patterns: Elements of Reusable Object-Oriented Software” en el que se recopilaban 23 patrones de diseño .

Design pattern HITOS Coplien y Schmidth. Pattern Languages of Program Design. 1995 Bushmann et al. Pattern-Oriented Software Architecture: A System of Patterns. 1996

Design pattern TIPOS DE PATRONES de Diseño de Arquitectura de Análisis de Testing para Web para Ambientes Distribuidos de Negocios de Procesos y Organizacionales …

Design pattern LENGUAJE DE PATRÓN En diseño, un lenguaje de patrón es un método estructurado para describir una serie de buenas prácticas de diseño en un área particular. Descubrir y nombrar los problemas más comunes en el campo de interés. Describir las características principales de las soluciones efectivas para llegar al objetivo marcado. Ayudar al diseñador a moverse de un problema a otro de una forma lógica.

CÓMO DOCUMENTAR UN PATRÓN Design pattern CÓMO DOCUMENTAR UN PATRÓN "Contexto" - ¿Bajo qué condiciones resolverá esta solución el problema? "Sistema de fuerzas" - Se puede considerar como el problema o el objetivo "Solución" - Una configuración que pone las fuerzas en equilibrio o resuelve el problema presentado Solución Sistemas de Fuerzas Contexto

CARACTERÍSTICAS DE UN PATRÓN Design pattern CARACTERÍSTICAS DE UN PATRÓN Resolver un problema recurrente Con una solución probada Que no sea evidente Se describe de manera abstracta UN PATRÓN SE DESCUBRE NO SE INVENTA

ELEMENTOS DE UN PATRÓN SEGÚN GoF Design pattern ELEMENTOS DE UN PATRÓN SEGÚN GoF Nombre del patrón: Nombre estándar del patrón por el cual será reconocido en la comunidad (normalmente se expresan en inglés). Clasificación del patrón: creacional, estructural o de comportamiento. Intención: ¿Qué problema resuelve el patrón? También conocido como: Otros nombres de uso común para el patrón. Motivación: Escenario de ejemplo para la aplicación del patrón. Aplicabilidad: Criterios de aplicabilidad del patrón. Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el patrón.

ELEMENTOS DE UN PATRÓN SEGÚN GoF Design pattern ELEMENTOS DE UN PATRÓN SEGÚN GoF Participantes: Enumeración y descripción de las entidades abstractas (y sus roles) que participan en el patrón. Colaboraciones: Explicación de las interrelaciones que se dan entre los participantes. Consecuencias: Consecuencias positivas y negativas en el diseño derivadas de la aplicación del patrón. Implementación: Técnicas o comentarios oportunos de cara a la implementación del patrón.

ELEMENTOS DE UN PATRÓN SEGÚN GoF Design pattern ELEMENTOS DE UN PATRÓN SEGÚN GoF Código de ejemplo: Código fuente ejemplo de implementación del patrón. Usos conocidos: Ejemplos de sistemas reales que usan el patrón. Patrones relacionados: Referencias cruzadas con otros patrones.

Design pattern PATRONES DE GoF De Creación Estructurales De Comportamiento Ámbito Clase Factory Method Adapter (de clase) Interpreter Template Method Objeto Abstract Factory Builder Prototype Singleton Adapter (de objetos) Bridge Composite Decorator Facade Flyweight Proxy Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor

William J. Brown, Raphael C. Malveau , Thomas J. Mowbray Design pattern ANTIPATRONES Los antipatrones son soluciones negativas que presentan más problemas que los que solucionan. AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. William J. Brown, Raphael C. Malveau , Thomas J. Mowbray

Design pattern ANTIPATRONES ¿Por qué estudiar antipatrones? Proveen experiencia del mundo real para reconocer problemas recurrentes en la industria del software, ofreciendo también una solución para sus implicaciones más comunes. Establecen un vocabulario común para identificar problemas y discutir soluciones. Un buen programador procurará evitar los antipatrones siempre que sea posible, lo que requiere su reconocimiento e identificación .

ANTIPATRONES DE DISEÑO Design pattern ANTIPATRONES DE DISEÑO Acoplamiento secuencial (sequential coupling): Construir una clase que necesita que sus métodos se invoquen en un orden determinado. BaseBean: Heredar funcionalidad de una clase utilidad en lugar de delegar en ella. Fallo de clase vacía (empty subclass failure): Crear una clase que no supera el test de la subclase vacía, es decir, que se comporta de manera diferente cuando se invoca desde una subclase que añade modificación alguna. Llamar a super (callsuper): Obligar a las subclases a llamar a un método de la superclase que ha sido sobrescrito. Modelo de dominio anémico (anemic domain model): Usar un modelo del dominio sin ninguna lógica de negocio. Esto no es un enfoque orientado a objetos porque cada objeto debería tener tanto propiedades como comportamiento asociado. Objeto sumidero (object cesspool): Reusar objetos no adecuados realmente para el fin que se persigue.

ANTIPATRONES DE DISEÑO Design pattern ANTIPATRONES DE DISEÑO Objeto todopoderoso (god object): Concentrar demasiada funcionalidad en una única parte del diseño (clase). Poltergeist: Emplear objetos cuyo único propósito es pasar la información a terceros objetos. Problema del círculo-elipse (circle-ellipse problem): Crear variables de tipo pensando en los valores de posibles subtipos. Problema del yoyó (yo-yo problem): Construir estructuras (por ejemplo, de herencia) que son difíciles de comprender debido a su excesiva fragmentación. Singletonitis: Abuso de la utilización del patrón singleton. YAFL (yet another layer, y otra capa más): Añadir capas innecesarias a un programa, biblioteca o framework. Esta tendencia se extendió bastante después de que se publicase el primer libro sobre patrones.

Design pattern EJEMPLO Una aplicación necesita tener una y solo una instancia de una clase determinada.

Design pattern

Design pattern

Design pattern

Design pattern

Design pattern

Design pattern Referencias [Alexander79] Alexander, Christopher: A Timeless Way of Building, Oxford University Press, 1979. [AIX77] Alexander, Christopher et al.: A Pattern Language, Oxford University Press, 1977. [BMMM98] Brown, W., Malveau, R., Mc Cormick III, H., Mowbray, T.: Antipatterns: Refactoring Software, Architectures and Project in Crisis, Wiley and Sons, 1998. [Buschman96] Buschmann, Frank et al.: Pattern Oriented Software Architecture, Volume 1: A System of Patterns, Willey & Sons, 1996. [Cueva04] Cueva Lovelle, Juan Manuel: Tecnología de Objetos: Patrones de Diseño, 2004. [Evitts00] Evitts, Paul: A UML Pattern Language, SAMS Publishing, 2000. [Fowler03] Fowler, Martin: Enterprise Application Architecture Patterns, Addison Wesley, 2003. [Fowler97] Fowler, Martin: Analysis Patterns: Reusable Object Models, Adisson Wesley, 1997. [Fowler99] Fowler, Martin: Refactoring: Improving the Design of Existing Code, Adisson Wesley, 1999. [Gall75] Gall, John: Systemantics: How Systems Work and Especially How They Fail, New York, Quadrangle, 1975. [GoF95] Gamma E., Helm, R., Johnson, R., Vlissides J.: Design Patterns: Elements of Reusable Object Oriented Software, Addison Wesley, 1995. [Hillside03] Hillside Group: Home of the Patterns Library, 2003 <en línea> http://hillside.net/. [Hophe03] Hophe, Gregor, Woolf, Robert: Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, Addisson Wesley, 2003. [Kerievsky04] Kerievsky, Joshua: Refactoring to Patterns, Addison-Wesley, 2004. [McCormick98] McCormick, Hays: Antipatterns Tutorial, 1998 <en línea> http://www.antipatterns.com/briefing/sld001.htm. [Microsoft03] Microsoft Corp: Enterprise Solution Patterns, Microsoft Press, 2003. [Microsoft04] Microsoft Corp: Enterprise Development Reference Architecture, Microsoft Press, 2004. [PPR04] C2 WikiWikiWeb: Portland Pattern Repository <en línea> http://c2.com/ppr/. [SAG04] Software Architecture Group at University Illinois at Urbana-Champaign, <en línea> http://wiki.cs.uiuc.edu/SAG/. [ST01] Shalloway, Alan; Trott James: Design Patterns Explained: A New perspective on Object Oriented Design, Pearson Education, 2001. [Vlissides98] Vlissides, John: Pattern Hatching: Design Patterns Applied, Addison Wesley, 1998.

Gracias por su atención Design pattern Gracias por su atención dario.cardacci@vaneduc.edu.ar UAI – Rosario 2007