1 / 29

Design pattern

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.

Télécharger la présentation

Design pattern

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

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

  4. CUÁL ES LA MEJOR SOLUCIÓN ¿Implementarmétodosconcretos en sub clasesconcretas? ¿Delegar en clasesmenosespecializadasdentro de unajerarquía (super clases)? ¿Componer o heredar? ¿Inversión de control o control directo? ¿Definirclasesabstractas? ¿Definiralgoritmosabstractos? ¿Cuáles la mejorsolución? Design pattern

  5. LOS HECHOS CONCRETOS Permanentementeadquirimosexperiencia Dominio Problema No se transmite en forma ordenada Los expertosaprendenporensayo y error Los expertosmanejan un metalenguaje ad-hoc Design pattern

  6. 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 " Design pattern Christopher Alexander

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

  8. HITOS Design pattern • 1987. Ward Cunningham y Kent Beck publicaron un artículo en OOPSLA-87 (Object-Oriented Programming, Systems, Languages, and Applications) titulado “UsingPatternLanguagesfor 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 “DesignPatterns:Elements of Reusable Object-Oriented Software”en el que se recopilaban 23 patrones de diseño .

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

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

  11. LENGUAJE DE PATRÓN Design pattern • 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.

  12. CÓMO DOCUMENTAR UN PATRÓN Design pattern "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

  13. CARACTERÍSTICAS DE UN PATRÓN Design pattern UN PATRÓN SE DESCUBRE NO SE INVENTA

  14. ELEMENTOS DE UN PATRÓN SEGÚN GoF Design pattern 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.

  15. ELEMENTOS DE UN PATRÓN SEGÚN GoF Design pattern 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.

  16. ELEMENTOS DE UN PATRÓN SEGÚN GoF Design pattern 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.

  17. PATRONES DE GoF Design pattern

  18. ANTIPATRONES Design pattern 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

  19. ANTIPATRONES Design pattern ¿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 .

  20. ANTIPATRONES DE DISEÑO Design pattern Acoplamiento secuencial (sequentialcoupling): 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 (emptysubclassfailure): 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 (anemicdomainmodel): 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 (objectcesspool):Reusar objetos no adecuados realmente para el fin que se persigue.

  21. ANTIPATRONES DE DISEÑO Design pattern Objeto todopoderoso (godobject): 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-ellipseproblem): 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 (yetanotherlayer, 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.

  22. EJEMPLO Design pattern Unaaplicaciónnecesitateneruna y solo unainstancia de unaclasedeterminada.

  23. Design pattern

  24. Design pattern

  25. Design pattern

  26. Design pattern

  27. Design pattern

  28. Design pattern

  29. Design pattern Gracias porsuatención dario.cardacci@vaneduc.edu.ar UAI – Rosario 2007

More Related