IS4.11.12.Tema - XI.Patrones de Diseño

Patrones de Diseo
Creado por: Javier Garzs Actualizado por: Santiago Moral

(santiago.moral@urjc.es)
Patrones, primer ejemplo
Primer ejemplo
Caso prctico: el (tpico) videoclub
Se pretende disear el software referente a un videoclub. Este software debe contemplar las pelculas, los clientes y los alquileres que estos ltimos realizan. Existen dos tipos de pelculas, los estrenos y las regulares, y el coste del alquiler vara en funcin de dichos tipos.
Javier Garzs, Introduccin a los patrones de diseo
Primer ejemplo
Diagrama de clases:
Cliente
1
Alquiler
-diasAlquilada
Pelcula
1
- titulo
+getCoste(diasAlquilada)
Comienza la implementacin
Realicemos el mtodo getCoste() de la clase Pelcula:
Sabemos que dependiendo de la categora de la pelcula (Estreno o Regular) se aplicarn tarifas distintas.
Cmo podemos implementar esto?
Aparece la lgica condicional

public class Pelicula { static final int REGULAR=0; static final int EXTRENO=1; private int categoria;
double getCoste(int diasAlquilada) { double result = 0; switch (getCategoria()) { case REGULAR: result += diasAlquilada*2; break; case ESTRENO: result += diasAlquilada*3; break; } return result; }
int [getDiasTopeAlquiler | getCostePenalizacinDia () | getDiasInhabilitacion | ]{ switch (getCategoria()) { case REGULAR: case ESTRENO: }
La lgica condicional se propaga

public class Alquiler {
private int diasAlquilada; static final int 50PORCIENTO; static final int 75PORCIENTO;
int getDiasAlquiladaPromocion (int promocion) switch (promocion) { case 50PORCIENTO: switch (Pelicula.getCategoria()) case REGULAR: case ESTRENO: case 75PORCIENTO: } }
La lgica condicional
Efectivamente, lo anterior funcionara, pero sera mantenible? :
A los dos meses de estar operativa la aplicacin los requisitos, como no, cambian, ahora aparece la categora clsicos, maana de los 80 y al otro en cartelera
En nuestra micro aplicacin tenemos que tocar 5 mtodos y dos clases
Si nuestra aplicacin tuviese 80 clases, 12 constantes de estado y 20 switch repartidos por distintas clases
Bad Smells en la propuesta actual

Sentencias Switch
- Existe una gran lgica condicional que depende del estado. - Frecuentemente, varias operaciones repetirn la misma estructura condicional, al aadir ms tipos tendremos que buscar todos los switch.
Duplicacin de cdigo
- La lgica condicional casi siempre produce duplicacin de cdigo
Este es el peor bad smell, el anticristo de la mantenibilidad.
Solucin?!
La esencia del problema

Problema: La clase pelcula guarda dos roles Solucin:
Pelcula
- titulo
PelculaRegular
PelculaEstreno
Todo resuelto?
Ms tarde observamos que una pelcula debe cambiar su categora en run-time:
Tendremos, por ejemplo:
Objeto_PeliculaEstreno Objeto_PeliculaRegular
Solucin: Podemos crear un nuevo objeto de la clase PeliculaEstreno, sacar el estado del objeto de PeliculaRegular, cargar todo en el objeto de Pelcula estreno, cambiar los apuntadores, matar el objeto de PeliculaRegular, tener cuidado de que ningn otro objeto le apuntase, etc.
De todas formas, el objeto no cambiara de clase, tendramos otro objeto de otra clase OID nico.
La esencia del problema

Una pelcula debe cambiar de categora pero un objeto no puede cambiar de clase
T: La relacin de herencia es invariable en el tiempo
Un objeto nunca puede cambiar de clase!

Cmo podemos solucionar este nuevo problema?
La solucin final
Solucin Final:
Pelicula
- titulo +getCoste(diasAlquilada)
Precio
PrecioRegular
PrecioEstreno
Ventajas
Nuevos estados y sus transiciones se aaden fcilmente
Transiciones de estado explcitas

Estados localizados y con posibilidad de ser compartidos No hay switch No hay cdigo repetido Etc.
Cul era el primer problema?

Realmente, los requisitos presentaban esencialmente este problema:
- Los objetos de pelcula cambian su comportamiento dependiendo de su estado y dicho comportamiento debe cambiar en run-time. - Las operaciones que cambian no deben programarse con mltiples sentencias condicionales porque hacen difcil el mantenimiento.
Visin
Cuntas veces ha aparecido este problema?
A cuantos diseadores le ha ocurrido?

No podramos haber saltado del primer diagrama de clases a la solucin final?
Cuntas veces aparece cdigo errneo por qu el diseador no sabe o no tiene tiempo de pensar la solucin correcta?
Cmo aumentara la calidad? Se reducira el tiempo?
Patrn State
Objetivo
Permite a un objeto alterar su comportamiento cuando su estado interno cambia.
Motivacin
Cuando un objeto cambia de estado puede responder de maneras diferentes a los mismos mensajes. La forma tradicional es poner sentencias condicionales.
Aplicabilidad
Un objeto cambia su comportamiento dependiendo de su estado y dicho comportamiento debe cambiar en run-time. Las operaciones que cambian se programan con mltiples sentencias condicionales que hacen difcil el mantenimiento.
State
Estructura
La visin formal
El comienzo del movimiento

Christopher Alexander escribe varios libros acerca del planeamiento urbano y la construccin de edificios.
El origen formal del trmino patrn se atribuye a l y a sus dos principales trabajos: A Pattern Language (Alexander, 1977) The timeless Way of Building (Alexander, 1979)
Patrones OO: Origen

1987. Ward Cunningham y Kent Beck aplican las ideas de Christopher para desarrollar un pequeo lenguaje de patrones, para aprender Smalltalk: Using Pattern Languages for ObjectOriented Programs En 1990 se inicia el trabajo del Gang of Four (GoF)
P. Coad, Object-Oriented Patterns, Comm. ACM, Vol. 35, No 9, Sep. 1992, pp. 152-159.
Patrones OO: Madurez y Difusin

E. Gamma, R. Helm, R. Johnson and J. Vlissides, Design patterns: Elements of Reusable Object Oriented Software, Addison-Wesley, 1995.
F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad and M. Stal, A System of Patterns: Pattern-Oriented Software Architecture, AddisonWesley,1996.
Definicin de patrn
Una arquitectura reusable que la experiencia ha mostrado que resuelve un problema comn en un contexto especfico
Dictionary of Object Technology, 1995
Definicin de patrn
Cada patrn describe un problema que ocurre una y otra vez en nuestro entorno, describiendo el ncleo de la solucin a ese problema, de tal manera que esa solucin pueda ser usada ms de un milln de veces sin hacerlo dos veces de la misma forma
(Alexander, 1977).
Definicin de patrn
Un patrn contempla, adems de la solucin a un problema en un contexto:
Recurrencia Enseanza
Nombre
Consecuencias
Que no son los patrones

Invenciones, teora o ideas no probadas
- Teoras? No, no, son pura prctica
Soluciones que slo han funcionado una vez Cualquier cosa vieja escrita en formato de patrones
Principios abstractos o heursticos

Aplicaciones universales para cualquier contexto Una panacea (solucin para cualquier mal)
Por qu usar patrones?
Una cosa que los diseadores expertos no hacen es resolver cada problema desde el principio [...]. Cuando encuentran una buena solucin la usan una y otra vez. Esta experiencia es lo que les hace expertos
(Gamma ,1995)
Por qu usar patrones?

Diseo de
sistemas escalables y reutilizables es complejo
Usar soluciones probadas

Aprovecharse de la experiencia, catalogarla y documentarla. Reutilizar conocimiento Componer un vocabulario para Ingenieros
El mercado
demanda rapidez y calidad
Disear bien a
la primera vez es imposible
Beneficios Potenciales
Mejora de la comunicacin, el ms potente.
Cmo podran varios arquitectos discutir el diseo de un edificio si slo conocen la palabra ladrillo? La semntica nos pierde.
Productividad y calidad, inmediatas cuando los equipos puedan sostener discusiones de diseo desde un alto nivel.
Clasificacin de los patrones

Diferentes rangos de escala o niveles de abstraccin:
Patrones de Anlisis Patrones Arquitectnicos
Patrones de Diseo
Idioms Patrones de Seguridad
Antipatterns (Ej. Copy and Paste Programming)

De dominios especficos
Patrones de Diseo
Patrones de Diseo
El objetivo que se pretende es conocer el principal catlogo sobre patrones de diseo:
Design Patterns. Elements of Reusable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides
Ha sido reeditado 32 veces.
Patrones de Diseo
http://www.javacamp.org/designPattern http://www.4shared.com/zip/c_uumpBU/The _Design_Patterns_Java_Compa.html
Patrones de Diseo
Patrones de Diseo, los ms destacados

Refinan un subsistema o componente de un sistema software.
Describen una estructura a la cual muchas veces recurrimos para resolver problemas de diseo.
No afectan a la arquitectura de un sistema No dependen del lenguaje de implementacin.
Permiten resolver problemas complejos y direccionan la cooperacin efectiva entre componentes
Descripcin de un patrn (1/4)

Intencin
- Qu hace el patrn? - Cul es su racionalidad e intencin? - Qu problema de diseo ataca?
Tambin conocido como

- Otros nombres del patrn
Motivacin
- Un escenario que ilustra el problema y como la estructura del patrn lo soluciona. El escenario ayuda a comprender la descripcin mas abstracta que sigue

Aplicabilidad
- En que situaciones es aplicable el patrn - Ejemplos de Diseos pobres solucionables con el patrn - Cmo reconocer estas situaciones
Estructura
- Una representacin grfica de las clases en el patrn
Participantes
- Descripcin de la responsabilidad de los objetos y clases participantes
Colaboraciones
- Diagramas de colaboracin entre los objetos y clases participantes

Consecuencias
- Cmo logra el patrn sus objetivos? - Cules son los resultados de usarlo? - Qu partes de la estructura puede variar de manera independiente?
Implementacin
- Qu tcnicas utilizar para implementar el patrn? - Hay caractersticas especficas del lenguaje?

Cdigo de ejemplo
- Fragmentos de cdigo que ilustran como implementar el patrn
Usos conocidos
- Ejemplos de uso del patrn en sistemas reales
Patrones relacionados
- Qu patrones estn fuertemente relacionados? - Cules son las diferencias importantes? - Con qu otros patrones se debera usar ste?
Dimensiones de organizacin
Por propsito
- Creacional - Estructura - Comportamiento
mbito
- Clase - Objeto
Organizacin del catalogo

Creational Patterns
Abstraen el proceso de instanciacin haciendo al sistema independiente de cmo los objetos son creados, compuestos o representados. Alternativas de diseo por herencia o delegacin.
Encapsulan el mecanismo de creacin.

Independencia de los tipos de objetos producto que manejemos.
Patrones de Creacin (Gamma, 95)

Abstract Factory
Provee una interfaz para crear una familia de objetos relacionados sin especificar sus clases concretas
Factory Method
Define una interfaz para crear un objeto, dejando a las subclases decidir el tipo especfico. Permite delegar la responsabilidad de instanciacin a subclases
Singleton
Asegura una sola instancia de un objeto y provee un punto de acceso global a l
Builder
Separa la construccin de un objeto complejo de su representacin, para que el mismo proceso de construccin permita crear varias representaciones
Prototype
Especifica el tipo de objetos a crear usando una instancia de creacin (prototipo), y crea nuevas instancias copiando el prototipo
EJERCICIO
Qu tipo de patrn utilizaras para creacin de la clase Videoclub?
Pelicula
- titulo +getCoste(diasAlquilada) +getCoste(diasAlquilada)
Precio
PrecioRegular
PrecioEstreno
Patrn Singleton (1/4)

Creamos una clase para lanzar una excepcin
class SingletonException extends RuntimeException { //new exception type for singleton classes public SingletonException() { super(); } public SingletonException(String s) { super(s); } }

Lanzamos la excepcin
class PrintSpooler { //this is a prototype for a printer-spooler class //such that only one instance can ever exist static boolean instance_flag=false; //true if 1 instance public PrintSpooler() throws SingletonException { if (instance_flag) throw new SingletonException("Only one spooler allowed"); else { Instance_flag = true; //set flag for 1 instance System.out.println("spooler opened"); } } public void finalize() { instance_flag = false; //clear if destroyed } }

Creando una instancia de la clase
public class singleSpooler { static public void main(String argv[]) { PrintSpooler pr1, pr2; //open one spooler--this should always work System.out.println("Opening one spooler"); try { pr1 = new PrintSpooler(); } catch (SingletonException e) { System.out.println(e.getMessage()); } //try to open another spooler --should fail System.out.println("Opening two spoolers"); try { pr2 = new PrintSpooler(); } catch (SingletonException e) { System.out.println(e.getMessage()); } } }

Structural Pattern
Determinan como combinar objetos y clases para definir estructuras complejas.
Comunicar dos clases incompatibles, Aadir funcionalidad a objetos ...
Patrones Estructurales (Gamma, 95)

Adapter
Convierte la interfaz de una clase en una interfaz que el cliente espera. Permite trabajar juntas a dos clases con interfaces incompatibles
Bridge
Desacopla una abstraccin de su implementacin y les permite variar independientemente
Composite
Compone objetos en jerarquas para representar relaciones parte-todo. Composite permite a los clientes tratar de la misma manera tanto a objetos individuales como a compuestos.
Decorator
Agrega dinmicamente nuevas responsabilidades a un objeto. Provee una alternativa muy flexible para agregar funcionalidad a una clase
Facade
Provee una interface nica para un conjunto de interfaces en un sistema. Define una interface de ms alto nivel que permite usar el sistema ms fcil
Patrones Estructurales (Gamma, 95)

Flyweight
Soporta la representacin de un gran nmero de objetos pequeos de una manera eficiente.
Proxy
Provee un representante de acceso a otro objeto
Ejemplo de Aplicacin
Problema?
Circulo Dibujo Cuadrado
Solucin: Composite
Solucin: Composite
Dibujo ElementoDibujo Client
Circulo
Linea
Grupo

Behavioral Patterns
Se ocupan de los algoritmos y reparto de responsabilidades. Describen los patrones de comunicacin entre objetos y clases.
Podremos definir abstracciones de algoritmos (Template Method)

Cooperaciones entre objetos para realizar tareas complejas, reduciendo las dependencias entre objetos (Iterator, Observer, etc.) Asociar comportamiento a objetos e invocar su ejecucin (Command, Strategy, etc.)
Comportamiento (Gamma, 95)

Chain of Responsibility
Evita el acoplamiento entre el que enva y el que recibe una peticin. Se encadenan los objetos que reciben las peticiones, el mensaje por la cadena hasta que alguno lo responda
Command
Encapsula una operacin en un objeto, permitiendo parametrizar operaciones, encolarlas, dejar log de ellas o deshacerlas
Interpreter
Dado un lenguaje, define una representacin de su gramtica que permita interpretar las sentencias del lenguaje
Iterator
Provee una forma de tener acceso secuencial a los elementos de un conjunto sin exponer la implementacin de ste ltimo

Mediator
Define un objeto que encapsula la forma en la cual interactan otros. Promueve el acoplamiento dbil
Memento
Sin violar el encapsulamiento, captura y externaliza el estado interno de un objeto, para que pueda ser recuperado ms adelante
Observer
Define una dependencia de uno a muchos de tal manera que cuando uno de ellos cambia, todos los que dependen de l son notificados y actualizados automticamente
State
Permite a un objeto cambiar su comportamiento cuando su estado interno cambia. El objeto parecer haber cambiado de clase

Strategy
Define una familia de algoritmos intercambiables y encapsulados. Permite variar el algoritmo independientemente de quien lo usa
Template Method
Define un esqueleto de un algoritmo, delegando algunos pasos a las subclases. Permite redefinir ciertos pedazos del algoritmo sin cambiar su estructura
Visitor
Representa una operacin que debe realizarse sobre los elementos de una estructura de objetos. Permite definir nuevas operaciones sin cambiar las clases de los objetos sobre las cuales operan
Observer (1/5)
Objetivo
Define una dependencia de uno a muchos entre objetos, de manera que cuando un objeto cambia todos los que tienen dependencia de l son informados.
Motivacin
En casi todas las aplicaciones hay objetos que cundo cambian su valor deben de informar a otros objetos para que cambien su estado en ese momento.
Aplicabilidad
Cuando una abstraccin tiene diferentes aspectos y se desea reutilizar algunos de ellos de forma separada. Cuando un cambio en un objeto necesita realizar cambios en otros y no se sabe a priori en cuantos objetos se hace este cambio.Cuando un objeto debe notificar a otros de algn cambio y no se desea que se acoplen entre ellos.
Observer (2/5)
Estructura
Observer (3/5)
Participantes
Subject: Conoce a sus observers, cualquier nmero de Observers puede observar a un Subject. Define un interfaz para admitir subscriptores. Observer: Define un interfaz para los objetos que deben ser notificados de los cambios en un Subject. ConcreteSubject: Guarda los estados de inters de un ConcreteObserver. Enva notificacin a sus observers cuando su estado cambia. ConcreteObserver: Mantiene una referencia a un ConcreteSubject. Implementa el interfaz Observer.
Observer (4/5)
Colaboraciones
Observer (5/5)
Consecuencias
Abstrae el acoplamiento entre Observer y Subject al definir un interfaz estndar para todos ellos. Soporta Broadcasting. Debido a que la interfaz es estndar puede provocar llamadas de actualizacin sobre Observers que no la necesitan.
Patrones relacionados
Mediator puede encapsular semnticas complejas de actualizacin. Singleton, al usar un Mediator puede ser importante que sea un Singleton.
Una clase que no usa Observer

Pudiramos encontrar algo como:
public class ControlDeTemperatura { GUI InterfazUsuario; public ControlDeTemperatura(InterfazUsuario Interfaz){ InterfazUsuario=Interfaz; } public void receiveTemperatura (int temperatura,int numSensor){ InterfazUsuario.nuevaTemperatura(temperatura, numSensor); } }
Una clase que usa Observer.

Cuando debiramos encontrar algo como:
public interface Observer {public void notify(float temperatura);}
public GUI implement Observer {public notify (float temperatura){...} }

public class Subject { Vector observers = new Vector(); public void addObserver(Observer observer){ observers.add(observer); } public void removeObserver(Observer observer) { observers.remove(observer); } public void notify(float valor){ for(int i=0; i<observers.size(); i++) ((Observer)observers.elementAt(i)).notify(valor)} } public class ControlDeTemperatura extend Subject { public void receiveTemperatura (int temperatura,int numSensor)}
CHAIN OF RESPONSIBILITY
Organizacion del catlogo

Propsito
Creacional Estructural
Adapter (Class) Adapter (Object) Bridge Composite Decorator Facade Flyweight Proxy
Comportamiento
Interpreter Template Method Chain of Responsibility Command Iterator Mediator memento Observer State Strategy Visitor
Alcance
Clase
Factory Method
Objeto Abstract Factory Builder Prototype Singleton
Ejemplo de Aplicacin
Cmo organizar el control de la aplicacin y, adems, agregar un mecanismo para la creacin de macros?
Command

IS4.11.12.Tema - XI.Patrones de Diseño

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

IS4.11.12.Tema - XI.Patrones de Diseño

Diunggah oleh

Hak Cipta:

Format Tersedia

Patrones de Diseo

Creado por: Javier Garzs Actualizado por: Santiago Moral

Patrones, primer ejemplo

Javier Garzs, Introduccin a los patrones de diseo

Javier Garzs, Introduccin a los patrones de diseo

Cmo podemos implementar esto?

Javier Garzs, Introduccin a los patrones de diseo

Aparece la lgica condicional

Javier Garzs, Introduccin a los patrones de diseo

La lgica condicional se propaga

Javier Garzs, Introduccin a los patrones de diseo

Bad Smells en la propuesta actual

Este es el peor bad smell, el anticristo de la mantenibilidad.

La esencia del problema

Javier Garzs, Introduccin a los patrones de diseo

Javier Garzs, Introduccin a los patrones de diseo

La esencia del problema

T: La relacin de herencia es invariable en el tiempo

Un objeto nunca puede cambiar de clase!

Javier Garzs, Introduccin a los patrones de diseo

Transiciones de estado explcitas

Javier Garzs, Introduccin a los patrones de diseo

Cul era el primer problema?

Javier Garzs, Introduccin a los patrones de diseo

A cuantos diseadores le ha ocurrido?

Javier Garzs, Introduccin a los patrones de diseo

Javier Garzs, Introduccin a los patrones de diseo

El comienzo del movimiento

Javier Garzs, Introduccin a los patrones de diseo

Patrones OO: Origen

Patrones OO: Madurez y Difusin

Javier Garzs, Introduccin a los patrones de diseo

Javier Garzs, Introduccin a los patrones de diseo

Javier Garzs, Introduccin a los patrones de diseo

Javier Garzs, Introduccin a los patrones de diseo

Que no son los patrones

Principios abstractos o heursticos

Javier Garzs, Introduccin a los patrones de diseo

Por qu usar patrones?

Javier Garzs, Introduccin a los patrones de diseo

Por qu usar patrones?

Usar soluciones probadas

Javier Garzs, Introduccin a los patrones de diseo

Javier Garzs, Introduccin a los patrones de diseo

Clasificacin de los patrones

Antipatterns (Ej. Copy and Paste Programming)

Javier Garzs, Introduccin a los patrones de diseo

Javier Garzs, Introduccin a los patrones de diseo

http://www.javacamp.org/designPattern http://www.4shared.com/zip/c_uumpBU/The _Design_Patterns_Java_Compa.html

Javier Garzs, Introduccin a los patrones de diseo

Javier Garzs, Introduccin a los patrones de diseo

Patrones de Diseo, los ms destacados

Permiten resolver problemas complejos y direccionan la cooperacin efectiva entre componentes

Javier Garzs, Introduccin a los patrones de diseo

Descripcin de un patrn (1/4)

Tambin conocido como

Javier Garzs, Introduccin a los patrones de diseo

Descripcin de un patrn (2/4)

Descripcin de un patrn (3/4)

Javier Garzs, Introduccin a los patrones de diseo

Descripcin de un patrn (4/4)

Javier Garzs, Introduccin a los patrones de diseo

Javier Garzs, Introduccin a los patrones de diseo