Tema 7: Patrones de diseño

Ingeniería del Software de Gestión II Grupo de Ingeniería del Software

Índice ♦ Introducción ♦ Patrones de diseño de uso común ♦ Bibliografía

Índice ♦ Introducción ♦ Patrones de diseño de uso común ♦ Bibliografía

Dónde estamos ♦  Conocemos ♦ La diferencia entre análisis y diseño ♦ Los principios de diseño y la importancia de estos ♦  Queremos saber ♦ Qué son los patrones de diseño y cómo nos pueden ayudar a obtener buenos diseños ♦ De dónde surgen los patrones de diseño ♦ Algunos de los patrones de diseño más comunes: Fábrica Simple, Fábrica Abstracta, Singleton, Fachada, Adaptador, Decorador, Proxy, Comando, Estrategia, Método Plantilla y Observador

Qué es un PD

Orígenes de los PP.DD

♦ Christopher Alexander (Viena, 1936)

1977

1979

Qué es un PD

Orígenes de los PP.DD

Ward Cunnighan & Kent Beck

OOPSLA 87 1. 

Window per Task

2. 

Few Panes

3. 

Standard Panes

4. 

Nouns and Verbs

5. 

Short Menus

Qué es un PD

Orígenes de los PP.DD ♦  1993. Beck y Booch sufragan un retiro en las montañas de colorado. Nace el HillSide

♦ 1994. Hillside organiza la primera edición del PLOP (Patterns Languages of Program Design). La banda de los cuatro venden más de 750 ejemplares de su libro (10 veces más que cualquier libro hasta entonces)

? Eric Gamma

Ralph Johnson

John Vlissides

Richard Helm

♦ Qué es un PD Definiciones

♦  En Ingeniería del Software (Gamma95, pág. 360) A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in OO systems. … The solution is customized and implemented to solve the problem in a particular context. • 

Técnica de descripción

• 

Par problema-solución

• 

Recurrente

• 

Sólo el núcleo, no es una solución completa

• 

Reutilizable

Patrón de diseño ♦ Nombre ♦ Problema ♦ Solución ♦ Ventajas e inconvenientes ♦ Detalles de implementación

Patrones de diseño Creacional

Fábrica Abstracta, Método Fábrica, Constructor, Prototipo, Singleton

Estructural

Adaptador, Puente, Compuesto, Decorador, Fachada, Peso Mosca, Proxy

De Comportamiento

Cadena de Responsabilidad, Comando, Iterador, Mediador, Memento, Observador, Estado, Estrategia, Visitante, Método Plantilla

¡ATENCIÓN! HAY MUCHOS OTROS PATRONES DE DISEÑO

¿Dónde encuentro todo esto? ♦  Basica (de referencia): ♦  “Design Patterns”, Gamma, Helm, Johnson, Vlissides, Addison-Wesley

♦  De apoyo: ♦  Historia de los patrones http://c2.com/cgi-bin/wiki?HistoryOfPatterns ♦  “Head First - Design Patterns”, Ed.- O’Reilly (2004). ♦  “UML y Patrones”, Craig Larman (1999). ♦  Wikipedia en ingles (Design Patterns)

Ejemplo: Patrón Fachada 1. Problema ♦  Se quiera proporcionar una interfaz sencilla para un subsistema complejo ♦  Se quiera desacoplar un subsistema de sus clientes y de otros subsistemas, haciéndolo mas independiente y portable ♦  Se quiera dividir los sistemas en niveles: las fachadas serían el punto de entrada a cada nivel

Ejemplo: Patrón Fachada 1. Problema (Ejemplo)

♦ Linkador

♦ Editor

♦ Depurador

♦ Compilador ♦ Compilar()

♦ Clases del ♦ subsistema de ♦ compilación

♦ AnaSin

♦ ASA

♦ AnaLex

♦ TabSim

♦ Token

Ejemplo: Patrón Fachada 2. Solución ♦ Clases del

♦ Fachada

♦ subsistema ♦ B

♦ A

♦ C

♦ 

♦ 

♦ D

♦ E

Los clientes se comunican con el subsistema a través de la fachada, que reenvía las peticiones a los objetos del subsistema apropiados y puede realizar también algún trabajo de traducción Los clientes que usan la fachada no necesitan acceder directamente a los objetos del sistema

Ejemplo: Patrón Fachada 3. Ventajas e Inconvenientes ♦  Oculta a los clientes de la complejidad del subsistema y lo hace más fácil de usar ♦  Favorece un acoplamiento débil entre el subsistema y sus clientes, consiguiendo que los cambios de las clases del sistema sean transparentes a los clientes ♦  Facilita la división en capas y reduce dependencias de compilación ♦  No se impide el acceso a las clases del sistema

Ejemplo: Patrón Fachada 4. Detalles de implementación ♦  Se puede reducir aún más el acoplamiento haciendo que la fachada sea una clase abstracta, de forma que se pueda escoger entre distintas implementaciones del subsistema ♦  Usando la visibilidad de paquete de Java puede ocultar el acceso a clases de un subsistema.

Índice ♦ Introducción ♦ Patrones de diseño de uso común ♦ Bibliografía

Clasificación Creacional

Fábrica Abstracta, Método Fábrica, Constructor, Prototipo, Singleton

Estructural

Adaptador, Puente, Compuesto, Decorador, Fachada, Peso Mosca, Proxy

De Comportamiento

Cadena de Responsabilidad, Comando, Iterador, Mediador, Memento, Observador, Estado, Estrategia, Visitante, Método Plantilla

La Fábrica Simple ♦  ¡OJO! Es una fábrica abstracta con un solo producto. NO es un PD. ♦  La Fábrica Simple sirve para encapsular el código de creación de objetos en una clase. FormaPreguntarFactory

llama ... IFormaPreguntar p; p = factory.create(); ...

create(…): IFormaPreguntar

crea

IFormaPreguntar IFormaPreguntar p = null; if (…) p = new PreguntaAzar(); else p = new PreguntaTodas(); return p;

PreguntaAzar

PreguntaTodas

A lo que crea una fábrica se les denomina productos

El Patron Fábrica Abstracta ♦  El PD Fábrica Abstracta proporciona una interfaz para crear familias de objetos relacionados o dependientes sin necesidad de especificar sus clases concretas

Client

La AbstractFactory define la interfaz de las fábricas concretas, que consiste en un conjunto de métodos para crear productos.

AbstractProductA

AbstractFactory ProductA2

createProductA()

ProductA1

createProductB()

ConcreteFactory1

ConcreteFactory2

createProductA()

createProductA()

createProductB()

createProductB()

Cada fábrica concreta crea el conjunto entero de productos.

Las fábricas concretas implementan las familias de producto. Para crear un producto, el cliente usa una de estas fábricas en lugar de instanciarlo directamente

AbstractProductB

ProductB2

Imagen basada en el libro Head First Design Patterns, O’Reilly

ProductB1

El Patrón Singleton ♦  El PD Singleton garantiza que una clase sólo tenga una instancia y proporciona un punto de acceso global a ella. PrinterManager El “truco” es poner el constructor privado. Así se evita que otras clases puedan crear instancias de PrinterManager

- instance: PrinterManager = null - PrinterManager() + getInstance(): PrinterManager + print(Document d)

Quien quiera usar el PrinterManager lo hará con este código…

... PrinterManager p = PrinterManager.getInstance(); p.print(d); El único objeto de tipo PrinterManager está en el atributo instance de la clase PrinterManager

PrinterManager es un singleton que maneja la cola de impresión para una impresora

if (instance == null) instance = new PrinterManager(); return instance

PrinterManager (Clase) instance (objeto de tipo PrinterManager)

Clasificación Creacional

Fábrica Abstracta, Método Fábrica, Constructor, Prototipo, Singleton

Estructural

Adaptador, Puente, Compuesto, Decorador, Fachada, Peso Mosca, Proxy

De Comportamiento

Cadena de Responsabilidad, Comando, Iterador, Mediador, Memento, Observador, Estado, Estrategia, Visitante, Método Plantilla

El Patrón Adaptador ♦  El PD Adaptador convierte la interfaz de una clase en otra interfaz que espera el cliente. El adaptador permite que clases con interfaces incompatibles puedan funcionar juntas. Client ILogin

login(name,pass): Boolean

HotmailLogin authenticate(name, pass): Boolean

adaptee

HotmailLoginAdapter login(name, pass): Boolean

Imagen obtenida del libro Head First Design Patterns, O’Reilly

El Patrón Decorador ♦  El PD Decorador añade responsabilidades adicionales a un objeto dinámicamente. Los decoradores proporcionan una alternativa flexible a hacer subclases para extender la funcionalidad. Un objeto se puede decorar con varios decoradores

Cipher Input Stream read()

Añade su propio comportamiento antes o después de delegar en el objeto que decora

Inflater Input Stream

InputStream read()

FileInputStream

FileInputStream

read()

Decorator read()

read() read()

CipherInputStream read() Los decoradores tienen el mismo supertipo que los objetos que decoran

Imagen basada en el libro Head First Design Patterns, O’Reilly

InflaterInputStream read()

El Patrón Fachada ♦  El PD Fachada proporciona una interfaz unificada a un conjunto de interfaces de un subsistema. La fachada define una interfaz de alto nivel que hace al subsistema más fácil de usar. Linkador

Editor

Depurador

Compilador Clases del subsistema de compilación

Compilar()

AnaSin

ASA

AnaLex

TabSim

Token

El Patrón Proxy ♦  El PD Proxy proporciona un sustituto a otro objeto para controlar su acceso.

Un objeto que muestra una imagen



No sabe que está usando un proxy. Para él resulta totalmente transparente

Image

paintImage(Graph ics g)

ImageFile paintImage(Graphics g)

ImageProxy realImage

image.paintImage(g)

Un proxy de la imagen (ImageProxy) Actúa de proxy para mostrar una imagen de “Loading” mientras carga la imagen

realImage.paintImage(g)

Una imagen (ImageFile)

Es el objeto que carga la imagen realmente

paintImage(Graphics g)

Clasificación Creacional

Fábrica Abstracta, Método Fábrica, Constructor, Prototipo, Singleton

Estructural

Adaptador, Puente, Compuesto, Decorador, Fachada, Peso Mosca, Proxy

De Comportamiento

Cadena de Responsabilidad, Comando, Iterador, Mediador, Memento, Observador, Estado, Estrategia, Visitante, Método Plantilla

El Patrón Estrategia ♦  El PD Estrategia define una familia de algoritmos, los encapsula y los hace intercambiables. Permite que el algoritmo varíe independientemente del cliente. PreguntaAzar CasillaCentral

pregunta(): Boolean

pregunta(): Boolean

PreguntaElegida formaPreguntar

preguntar(): Boolean

IFormaPreguntar pregunta(): Boolean

PreguntaTodas preguntar(): Boolean

Estrategias (Formas de preguntar)

El Patrón Método Plantilla ♦  El PD Método Plantilla define el esqueleto de un algoritmo en un método, dejando algunos pasos a sus subclases, es decir, deja que las subclases redefinan ciertos pasos del algoritmo sin cambiar su estructura public final void preparar() {

Bebida preparar() hervir() ponerEnVaso() echar() condimentar()

hervir();

Métodos concretos (finales)

Método plantilla

echar(); ponerEnVaso(); condimentar();

Método primitivo (abstracto)

}

Café echar()

Té echar() condimentar()

Método gancho (se da una implementación por defecto que se puede refinar opcionalmente)

El Patrón Observador ♦  El PD Observador define una dependencia uno-a-varios entre objetos de manera que cuando un objeto cambia de estado, se notifica a todas sus dependencias y se actualizan automáticamente. El sujeto observado avisa a los observadores cuando se ha producido algún 2% cambio C, 7 13º

Observers

WeatherData (Subject)

13º C,



Subject register(Observer o) remove(Observer o) notifyObservers()

observers

Observer update(temp: float, hum: float)

*

ExternalDisplay (Observer)

StatisticsDisplay

72%

StatisticsDisplay (Observer)

CurrentConditio nsDisplay (Observer) Los observadores se registran utilizando el método register

subject

update(temp, hum) display()

ExternalDisplay update(temp, hum) display()

WeatherData register(Observer o) remove(Observer o) notifyObservers() getTemperature(): float getHumidity(): float measurementsChanged()

CurrentConditionsDisplay subject

update(temp, hum) display()

Índice ♦ Introducción ♦ Patrones de diseño de uso común ♦ Bibliografía

Bibliografía ♦  Basica (de referencia): ♦  “Design Patterns”, Gamma, Helm, Johnson, Vlissides, Addison-Wesley

♦  De apoyo: ♦  “Head First - Design Patterns”, Ed.- O’Reilly (2004). ♦  “UML y Patrones”, Craig Larman (1999). ♦  Wikipedia en ingles (Design Patterns)

!Gracias! ♦  ¿Podemos mejorar esta presentación? ♦ Mándanos un email a [email protected] ♦ Visite la web de la asignatura ev.us.es