1 Arquitectura software y patrones “Una arquitectura orientada a objetos bien estructurada está llena de patrones. La calidad de un sistema orientado a objetos se mide por la atención que los diseñadores han prestado a las colaboraciones entre sus objetos.”
“Los patrones conducen a arquitecturas más pequeñas, más simples y más comprensibles” G. Booch
2 Diseño orientado a objetos “Diseñar software orientado a objetos es difícil pero diseñar software orientado a objetos reutilizable es más difícil todavía. Diseños generales y flexibles son muy difíciles de encontrar la primera vez”
¿Qué conoce un programador experto que desconoce uno inexperto?
Reutilizar soluciones que funcionaron en el pasado: Aprovechar la experiencia
3 Patrones Describen un problema recurrente y una solución. Cada patrón nombra, explica, evalúa un diseño recurrente en sistemas OO. Elementos principales: Nombre Problema Solución: Descripción abstracta Consecuencias
4 Patrones Patrones de código Nivel de lenguaje de programación Frameworks Diseños específicos de un dominio de aplicaciones. Patrones de diseño Descripciones de clases cuyas instancias colaboran entre sí que deben ser adaptados para resolver problemas de diseño general en un particular contexto. Un patrón de diseño identifica: Clases, Roles, Colaboraciones y la distribución de responsabilidades.
5 Patrones y frameworks Un framework es una colección organizada de clases que constituyen un diseño reutilizable para una clase específica de software. Necesario adaptarlo a una aplicación particular. Establece la arquitectura de la aplicación Diferencias: Patrones son más abstractos que los frameworks Patrones son elementos arquitecturales más pequeños Patrones son menos especializados
6 Observer Estructura
7 Observer Colaboración
8 Modelo-Vista-Control Utilizado para construir interfaces de usuario en Smalltalk-80. Basado en tres tipos de objetos: Modelo: objetos del dominio Vista: objetos presentación en pantalla (interfaz de usuario) Controlador: define la forma en que la interfaz reacciona a la entrada del usuario. Desacopla el modelo de las vistas.
1tr 3tr 4tr 2tr (Gp:) 1tr. 2tr. 3tr. 4tr. Este 20 25 90 20 Oeste 30 38 32 32 Norte 47 47 45 45
Vistas t1=20 t2=25 t3=90 t4=20 Modelo
10 Modelo-Vista-Control Utiliza los siguientes patrones: Observer Composite Strategy Decorator Factory method
11 Plantilla de definición Nombre Propósito ¿Qué hace?, ¿Cuál es su razón y propósito?, ¿Qué cuestión de diseño particular o problema aborda? Sinónimos Motivación Escenario que ilustra un problema particular y cómo el patrón lo resuelve.
12 Plantilla de definición Aplicabilidad ¿En qué situaciones puede aplicarse?, ¿Cómo las reconoces?, ejemplos de diseños que pueden mejorarse. Estructura Diagramas de clases que ilustran la estructura Participantes Clases que participan y sus responsabilidades Colaboraciones Diagramas de interacción que muestran cómo colaboran los participantes.
13 Plantilla de definición Consecuencias ¿Cómo alcanza el patrón sus objetivos?, ¿Cuáles son los compromisos y resultados de usar el patrón?, Alternativas, Costes y Beneficios Implementación Técnicas, heurísticas y consejos para la implementación ¿Hay cuestiones dependientes del lenguaje? Ejemplo de Código Usos conocidos Patrones relacionados
14 Clasificación Ámbito (Gp:) Propósito (Gp:) Estructural (Gp:) Comportamiento (Gp:) Creación (Gp:) Herencia (Gp:) Compo- sición (Gp:) Factory Method (Gp:) Adapter (Gp:) Interpreter Template Method (Gp:) Abstract Factory Builder Prototype Singleton (Gp:) Adapter Bridge Composite Decorator Facade Flyweight Proxy (Gp:) Chain of Responsability Command Iterator Mediator Memento Observer State Strategy Visitor
15 ¿A qué ayudan los patrones? Encontrar clases de diseño Especificar interfaces “Programar hacia la interfaz, no hacia la implementación” No declarar variables de clases concretas sino abstractas. Patrones de creación permiten que un sistema esté basado en términos de interfaces y no en implementaciones. Favorecen la reutilización a través de la composición en vez de la herencia
16 Herencia vs. Clientela Relación fija
Reuso “caja blanca” Relación variable Reuso “caja negra” Clase abstracta Interfaz
| Página siguiente |