Introducción a los Patrones de Diseño

1. Introducción a los Patrones de Diseño Javier Garzás jgarzas@gmail.com

2. Patrones, primer ejemplo

3. Patrones, desde la visión pragmática • Caso práctico: el (típico) videoclub • Se pretende diseñar el software referente a un videoclub. • Este software debe contemplar las películas, los clientes y los alquileres que estos últimos realizan. • Existen dos tipos de películas, los estrenos y las regulares, y el coste del alquiler varía en función de dichos tipos.

4. Patrones, desde la visión pragmática • Diagrama de clases: Película Alquiler * 1 Cliente - titulo 1 -diasAlquilada * +getCoste(diasAlquilada)

5. Comienza la implementación • Realicemos el método getCoste() de la clase Película: • Sabemos que dependiendo de la categoría de la película (Estreno o Regular) se aplicarán tarifas distintas. • ¿Cómo podemos implementar esto? • …

6. Aparece la lógica 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 += 2; if (diasAlquilada>2) result += (diasAlquilada-2)*1.5; break; case ESTRENO: result += diasAlquilada*3; break; } return result; } int [getDiasTopeAlquiler | getCostePenalizaciónDia () | getDiasInhabilitacion | …]{ switch (getCategoria()) { case REGULAR: … case ESTRENO: … } …

7. La lógica 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 ESTRENO: } }

8. La horrible lógica condicional • Efectivamente, lo anterior funcionaría, pero… ¿sería mantenible? : • A los dos meses de estar operativa la aplicación los requisitos, como no, cambian, ahora aparece la categoría “clásicos”, mañana “de los 80” y al otro “en cartelera”…  Si nuestra aplicación tuviese 80 clases, 12 constantes de estado y 20 switch repartidos por distintas clases… En nuestra micro aplicación tenemos que tocar 5 métodos y dos clases

9. Bad Smells en la propuesta actual • Sentencias Switch • Existe una gran lógica condicional que depende del estado. • Frecuentemente, varias operaciones repetirán la misma estructura condicional, al añadir más tipos tendremos que buscar todos los switch. • Duplicación de código • La lógica condicional casi siempre produce duplicación de código • Este es el peor bad smell, el anticristo de la mantenibilidad ¡¿Solución?!

10. Película - titulo +getCoste(diasAlquilada) PelículaRegular PelículaEstreno La esencia del problema • Problema: La clase película guarda dos roles • Solución:

11. ¿Todo resuelto? • Más tarde observamos que una película debe cambiar su categoría en run-time: • Tendremos, por ejemplo: • Objeto_PeliculaEstreno  Objeto_PeliculaRegular • Solución: Podemos crear un nuevo objeto de la clase PeliculaEstreno, sacar el estado del objeto de PeliculaRegular, cargar todo en el objeto de Película estreno, cambiar los apuntadores, matar el objeto de PeliculaRegular, tener cuidado de que ningún otro objeto le apuntase, etc. • De todas formas, el objeto no cambiaría de clase, tendríamos otro objeto de otra clase… OID único.

12. La esencia del problema • Una película debe cambiar de categoría pero un objeto no puede cambiar de clase  Tª:La relación de herencia es invariable en el tiempo ¡Un objeto nunca puede cambiar de clase! • ¿Cómo podemos solucionar este nuevo problema?

13. La solución final • Solución Final: Pelicula Precio - titulo +getCoste(diasAlquilada) +getCoste(diasAlquilada) PrecioRegular PrecioEstreno

14. Ventajas • Ahora, nuevos estados y sus transiciones se añaden fácilmente • Transiciones explícitas • Estados localizados y con posibilidad de ser compartidos • No hay swtich • No hay código repetido • Etc.

15. ¿Cuál era el primer problema? • Realmente, los requisitos presentaban esencialmente este problema: • Los objetos de película cambian su comportamiento dependiendo de su estado y dicho comportamientodebe cambiar en run-time. • Las operaciones que cambian no deben programar se con múltiples sentencias condicionales quehacen difícil el mantenimiento.

16. Visión pragmática • ¿Cuántas veces ha aparecido este problema? • ¿A cuantos diseñadores le ha ocurrido? • ¿No podríamos haber saltado del primer diagrama de clases a la solución final? • ¿Cuántas veces aparece código erróneo por qué el diseñador no sabe o no tiene tiempo de pensar la solución correcta? • ¿Cómo aumentaría la calidad? • ¿Se reduciría el tiempo?

17. Patrón State • Objetivo Permite a un objeto alterar su comportamiento cuando su estado interno cambia. • Motivación Cuando un objeto cambia de estado puede responder de maneras diferentes a los mismos mensajes. La forma tradicional es poner sentenciascondicionales. • Aplicabilidad Un objeto cambia su comportamiento dependiendo de su estado y dicho comportamientodebe cambiar en run-time. Las operaciones que cambian se programan con múltiples sentencias condicionales quehacen difícil el mantenimiento.

18. State • Estructura

19. La visión formal

20. El comienzo del movimiento • Christopher Alexander escribe varios libros acerca del planeamiento urbano y la construcción de edificios. • El origen formal del término patrón se atribuye a él y a sus dos principales trabajos: • A Pattern Language (Alexander, 1977) • The timeless Way of Building (Alexander, 1979)

21. Patrones OO: Origen • 1987. Ward Cunningham y Kent Beck aplican las ideas de Christopher para desarrollar un pequeño lenguaje de patrones, para aprender Smalltalk: “Using Pattern Languages for Object-Oriented 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.

22. Patrones OO: Madurez y Difusión • 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”, Addison-Wesley,1996.

23. Definición de patrón “Una arquitectura reusable que la experiencia ha mostrado que resuelve un problema común en un contexto específico” Dictionary of Object Technology, 1995

24. ¿Por qué usar patrones? “Una cosa que los diseñadores expertos no hacen es resolver cada problema desde el principio [...]. Cuando encuentran una buena solución la usan una y otra vez. Esta experiencia es lo que les hace expertos” (Gamma ,1995)

25. Beneficios Potenciales • Mejora de la comunicación, el más potente. • ¿Cómo podrían varios arquitectos discutir el diseño de un edificio si sólo conocen la palabra ladrillo? • ¿Cómo podrían los electrónicos diseñar fuentes si no existiese la palabra “rectificador”, sólo resistencia, transistor, etc.? • Productividad y calidad, inmediatas cuando los equipos puedan sostener discusiones de diseño desde un alto nivel

26. Clasificación de los patrones • Diferentes rangos de escala o niveles de abstracción: • Patrones Arquitectónicos • Patrones de Diseño • Patrones de Análisis • Idioms • Antipatterns • De dominios específicos

27. Patrones de Diseño

28. Patrones de Diseño • El objetivo que se pretende es conocer el principal catálogo sobre patrones de diseño: • “Design Patterns. Elements of Reusable Object-Oriented Software”, by Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides

29. Patrones de Diseño, los más destacados • Refinan un subsistema o componente de un sistema software. • Describen una estructura a la cual muchas veces recurrimos para resolver problemas de diseño. • Patrones de escala media. • No afectan a la arquitectura de un sistema • No dependen del lenguaje de implementación. • Permiten resolver problemas complejos y direccionan la cooperación efectiva entre componentes

30. Organización del catalogo • Creational Patterns • Abstraen el proceso de instanciación haciendo al sistema independiente de cómo los objetos son creados, compuestos o representados. • Alternativas de diseño por herencia o delegación. • Encapsulan el mecanismo de creación. • Independencia de los tipos de objetos “producto” que manejemos.

31. Patrones de Creación (Gamma, 95) • Abstract Factory Provee una interfaz para crear una familia de objetos relacionados sin especificar sus clases concretas • Factory Method Define una interface para crear un objeto, dejando a las subclases decidir el tipo específico. Permite delegar la responsabilidad de instanciación a subclases • Singleton Asegura una sola instancia de un objeto y provee un punto de acceso global a él • Builder Separa la construcción de un objeto complejo de su representación, para que el mismo proceso de construcción permita crear varias representaciones • Prototype Especifica el tipo de objetos a crear usando una instancia de creación (prototipo), y crea nuevas instancias copiando el prototipo

32. Organización del catalogo • Structural Pattern • Determinan como combinar objetos y clases para definir estructuras complejas. • Comunicar dos clases incompatibles, • Añadir funcionalidad a objetos • ...

33. 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 abstracción de su implementación y les permite variar independientemente • Composite Compone objetos en jerarquías para representar relaciones parte-todo. Composite permite a los clientes tratar de la misma manera tanto a objetos individuales como a compuestos. • Decorator Agrega dinámicamente 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 más alto nivel que permite usar el sistema más fácil

34. Patrones Estructurales (Gamma, 95) • Flyweight Soporta la representación de un gran número de objetos pequeños de una manera eficiente. • Proxy Provee un representante de acceso a otro objeto

35. Organización del catalogo • Behavioral Patterns • Se ocupan de los algoritmos y reparto de responsabilidades. • Describen los patrones de comunicación 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 ejecución (Command, Strategy, etc.)

36. Comportamiento (Gamma, 95) • Chain of Responsibility Evita el acoplamiento entre el que envía y el que recibe una petición. Se encadenan los objetos que reciben las peticiones, el mensaje por la cadena hasta que alguno lo responda • Command Encapsula una operación en un objeto, permitiendo parametrizar operaciones, encolarlas, dejar log de ellas o deshacerlas • Interpreter Dado un lenguaje, define una representación de su gramática que permita interpretar las sentencias del lenguaje • Iterator Provee una forma de tener acceso secuencial a los elementos de un conjunto sin exponer la implementación de éste último

37. Comportamiento (Gamma, 95) • Mediator Define un objeto que encapsula la forma en la cual interactúan otros. Promueve el acoplamiento débil • Memento Sin violar el encapsulamiento, captura y externaliza el estado interno de un objeto, para que pueda ser recuperado más 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 automáticamente • State Permite a un objeto cambiar su comportamiento cuando su estado interno cambia. El objeto parecerá haber cambiado de clase

38. Comportamiento (Gamma, 95) • 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 operación 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

39. Descripción de algunos patrones concretos

40. 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. • Motivación En casi todas las aplicaciones hay objetos que cuándo cambian su valor deben deinformar a otros objetos para que cambien su estado en ese momento. • Aplicabilidad Cuando una abstracción 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 algún cambio y no se desea que seacoplenentre ellos.

41. Observer (2/5) • Estructura

42. Observer (3/5) • Participantes • Subject: Conoce a sus observers, cualquier número de Observers puede observar a unSubject. 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 interés de un ConcreteObserver. Envíanotificación a sus observers cuando su estado cambia. • ConcreteObserver:Mantiene una referencia a un ConcreteSubject. Implementa el interfaz Observer.

43. Observer (4/5) • Colaboraciones

44. Observer (5/5) • Consecuencias Abstrae el acoplamiento entre Observer y Subject al definir un interfaz estándar paratodos ellos. Soporta Broadcasting. Debido a que la interfaz es estándar puede provocar llamadas de actualización sobre Observers que no la necesitan. • Patrones relacionados Mediator puede encapsular semánticas complejas de actualización. Singleton, al usar un Mediator puede ser importante que sea un Singleton.

45. Una “clase” que no usa Observer • Pudiéramos encontrar algo tan desagradable como: public class ControlDeTemperatura{ GUI InterfazUsuario; public ControlDeTemperatura(InterfazUsuario Interfaz){ InterfazUsuario=Interfaz; } public void receiveTemperatura (int temperatura,int numSensor){ InterfazUsuario.nuevaTemperatura(temperatura, numSensor); } }

46. Una clase que usa Observer. • Cuando debiéramos encontrar algo tan agradable 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)}

47. “Una cosa que los diseñadores expertos no hacen es resolver cada problema desde el principio [...]. Cuando encuentran una buena solución la usan una y otra vez. Esta experiencia es lo que les hace expertos” (Gamma ,1995)

48. “Cuando todos compartamos nuestro conocimiento en diseño, todos podremos construir con ese conocimiento y de este modo mejorar en vez de reinventar las mismas soluciones una y otra vez.” (Garzás, 2000)