Your SlideShare is downloading. ×
Introducción a los Patrones de Diseño Software
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Introducción a los Patrones de Diseño Software

4,509
views

Published on

Introducción a los Patrones de Diseño Software

Introducción a los Patrones de Diseño Software

Published in: Technology

0 Comments
18 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,509
On Slideshare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
0
Comments
0
Likes
18
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Javier Garzás www.javiergarzas.com Introducción a los Patrones de Diseño
  • 2. Patrones, primer ejemplo
  • 3. Javier Garzás ©, Introducción a los patrones de diseño 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. Javier Garzás ©, Introducción a los patrones de diseño Patrones, desde la visión pragmática Película Cliente Alquiler * * 1 1 - titulo +getCoste(diasAlquilada)  Diagrama de clases: -diasAlquilada
  • 5. Javier Garzás ©, Introducción a los patrones de diseño 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. Javier Garzás ©, Introducción a los patrones de diseño 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. Javier Garzás ©, Introducción a los patrones de diseño 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. Javier Garzás ©, Introducción a los patrones de diseño 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”… En nuestra micro aplicación tenemos que tocar 5 métodos y dos clases Si nuestra aplicación tuviese 80 clases, 12 constantes de estado y 20 switch repartidos por distintas clases…
  • 9. Javier Garzás ©, Introducción a los patrones de diseño 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. Javier Garzás ©, Introducción a los patrones de diseño La esencia del problema Película - titulo +getCoste(diasAlquilada) PelículaEstrenoPelículaRegular  Problema: La clase película guarda dos roles  Solución:
  • 11. Javier Garzás ©, Introducción a los patrones de diseño ¿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. Javier Garzás ©, Introducción a los patrones de diseño La esencia del problema ¡Un objeto nunca puede cambiar de clase!  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  ¿Cómo podemos solucionar este nuevo problema?
  • 13. Javier Garzás ©, Introducción a los patrones de diseño La solución final Precio +getCoste(diasAlquilada) PrecioEstrenoPrecioRegular  Solución Final: Pelicula - titulo +getCoste(diasAlquilada)
  • 14. Javier Garzás ©, Introducción a los patrones de diseño 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. Javier Garzás ©, Introducción a los patrones de diseño ¿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 comportamiento debe cambiar en run-time. - Las operaciones que cambian no deben programar se con múltiples sentencias condicionales que hacen difícil el mantenimiento.
  • 16. Javier Garzás ©, Introducción a los patrones de diseño 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. Javier Garzás ©, Introducción a los patrones de diseño 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 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 múltiples sentencias condicionales que hacen difícil el mantenimiento.
  • 18. Javier Garzás ©, Introducción a los patrones de diseño State  Estructura
  • 19. La visión formal
  • 20. Javier Garzás ©, Introducción a los patrones de diseño 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. Javier Garzás ©, Introducción a los patrones de diseño 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. Javier Garzás ©, Introducción a los patrones de diseño 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. Javier Garzás ©, Introducción a los patrones de diseño 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. Javier Garzás ©, Introducción a los patrones de diseño ¿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. Javier Garzás ©, Introducción a los patrones de diseño 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. Javier Garzás ©, Introducción a los patrones de diseño 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. Javier Garzás ©, Introducción a los patrones de diseño 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. Javier Garzás ©, Introducción a los patrones de diseño 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. Javier Garzás ©, Introducción a los patrones de diseño 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. Javier Garzás ©, Introducción a los patrones de diseño 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. Javier Garzás ©, Introducción a los patrones de diseño 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. Javier Garzás ©, Introducción a los patrones de diseño 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. Javier Garzás ©, Introducción a los patrones de diseño 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. Javier Garzás ©, Introducción a los patrones de diseño 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. Javier Garzás ©, Introducción a los patrones de diseño 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. Javier Garzás ©, Introducción a los patrones de diseño 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. Javier Garzás ©, Introducción a los patrones de diseño 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. Javier Garzás ©, Introducción a los patrones de diseño 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 de informar 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 se acoplen entre ellos.
  • 41. Javier Garzás ©, Introducción a los patrones de diseño Observer (2/5)  Estructura
  • 42. Javier Garzás ©, Introducción a los patrones de diseño Observer (3/5)  Participantes  Subject: Conoce a sus observers, cualquier número 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 interés de un ConcreteObserver. Envía notificación a sus observers cuando su estado cambia.  ConcreteObserver: Mantiene una referencia a un ConcreteSubject. Implementa el interfaz Observer.
  • 43. Javier Garzás ©, Introducción a los patrones de diseño Observer (4/5)  Colaboraciones
  • 44. Javier Garzás ©, Introducción a los patrones de diseño Observer (5/5)  Consecuencias Abstrae el acoplamiento entre Observer y Subject al definir un interfaz estándar para todos 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. Javier Garzás ©, Introducción a los patrones de diseño Una “clase” que no usa Observer public class ControlDeTemperatura { GUI InterfazUsuario; public ControlDeTemperatura(InterfazUsuario Interfaz){ InterfazUsuario=Interfaz; } public void receiveTemperatura (int temperatura,int numSensor){ InterfazUsuario.nuevaTemperatura(temperatura, numSensor); } }  Pudiéramos encontrar algo tan desagradable como:
  • 46. Javier Garzás ©, Introducción a los patrones de diseño 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. Javier Garzás ©, Introducción a los patrones de diseño “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. Javier Garzás ©, Introducción a los patrones de diseño “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)