2. Patrón de Diseño
“Los patrones de diseño son el esqueleto de las soluciones a problemas comunes en
el desarrollo de software.”
• Christopher Alexander ((Arquitecto/Urbanista)(1977):
..Cada patrón describe un problema que ocurre una y otra vez en nuestro
entorno, y describe la esencia de la solución a ese problema, de tal modo que
pueda utilizarse esta solución un millón de veces más, sin siquiera hacerlo de
la misma manera dos veces”
3. Un patrón es:
• Una solución a un problema en un contexto particular
• Recurrente (lo que hace la solución relevante a otras situaciones)
• Enseña (permite entender cómo adaptarlo a la variante particular del problema donde se
quiere aplicar)
• Tiene un nombre para referirse al patrón
Para que una solución sea tomada como un patrón debe cumplir al menos estos dos requisitos:
• Efectivo!
• Reutilizable!
4. Los PATRONES DE DISEÑO pretenden.. No pretenden..
• Evitar la reiteración en la búsqueda de soluciones
a problemas ya conocidos y solucionados
anteriormente.
• Estandarizar el modo en que se realiza el diseño.
• Ayudar a la comprensión de un sistema
rápidamente cuando está documentado con los
patrones que se usaron.
• Formalizar un vocabulario común entre
diseñadores.
Lenguajes de patrones
• Imponer ciertas alternativas
de diseño frente a otras
----------------------------------------
• No es obligatorio utilizar los
patrones.
• Abusar o forzar el uso de los
patrones puede ser un error.
ANTIPATRÓ
N
5. Nombre del patrón.
• Describe el problema de diseño.
Problema.
• Describe cuándo aplicar el patrón.
• Explica el problema y su contexto.
Solución.
• Elementos que forman el diseño,
relaciones, responsabilidades.
• No un diseño concreto, sino una
plantilla que puede aplicarse en
muchas situaciones distintas.
Consecuencias.
• Resultados, ventajas e inconvenientes
de aplicar el patrón.
• P.ej.: relación entre eficiencia en
espacio y tiempo; cuestiones de
implementación etc.
8. Además, Patrones de Diseño Fundamentales..
• DELEGATION
Cuando se quiere extender y reutilizar la funcionalidad
de una clase sin utilizar HERENCIA.
Ventajas:
• En vez de herencia múltiple
• Cuando una clase que hereda de otra quiere ocultar algunos
de los métodos heredados
• Compartir código que no se puede heredar
12. Además, Patrones de Diseño Fundamentales..
• INTERFACE
Definir un comportamiento independiente de donde
vaya a ser utilizado
• MARKER INTERFACE
Sirve para indicar atributos semánticos de una clase.
Ventajas:
• Se puede preguntar si un objeto pertenece a una clase de un determinado
tipo o no.
• Se utiliza en clases de utilidades que tienen que determinar algo sobre
objetos sin asumir que son instancias de una determinada clase o no.
13. • PatrÓN SINGLETON
Asegurar que una clase tenga una sola instancia y
proporcionar un punto de acceso global a ella
Es importante asegurar que una clase tenga una sola instancia, por ejemplo:
• Un gestor de ventanas
• Una única cola de impresión
• Un único sistema de ficheros
¿Cómo asegurarlo? una variable global hace el objeto accesible, pero se puede
instanciar varias veces.
Responsabilidad de la clase misma: actuar sobre el mensaje de creación de instancias
14. • PatrÓN Factory Method
Define una interfaz para crear un objeto, pero deja que sean
las subclases quienes decidan qué clase instanciar.
• PatrÓN PROXY
Proporcionar un representante de otro objeto para controlar el acceso
a este.
• PatrÓN ADAPTER
Permite trabajar juntas a clases con interfaces diferentes a través de la
creación de un objeto común mediante el que puedan comunicarse e
interactuar.
15. • PatrÓN COMPOSITE
Facilita la creación de jerarquías de objetos donde cada objeto se
puede tratar de forma independiente o como un conjunto de objetos
anidados a través de la misma interfaz.
• PatrÓN FACADE
Proporciona una interfaz unificada para un conjunto de interfaces de
un subsistema. Define una interfaz de alto nivel que hace que el
subsistema sea más fácil de usar.
• PatrÓN CHAIN OP RESPONSABILITY
Evita acoplar el emisor de una petición a su receptor dando a más de
un objeto la posibilidad de responder a una petición
16. • PatrÓN ITERATOR
Define una interfaz que declara los métodos necesarios para acceder
secuencialmente a un grupo de objetos de una colección.
Algunos de los métodos comunes que se definen en la interfaz Iterador son:
• Primero()
• Siguiente()
• HayMas()
• ElementoActual()
• PatrÓN MEDIATOR
Define un objeto que encapsula la manera en que interactúan un
conjunto de objetos entre ellos.
17. • PatrÓN MEMENTO
Su finalidad es almacenar el estado de un objeto (o del sistema completo)
en un momento dado de manera que se pueda restaurar en ese punto de manera
sencilla.
PatrÓN Observer
Define una dependencia del tipo uno-a-muchos entre objetos, de
manera que cuando uno de los objetos cambia su estado, notifica este
cambio a todos los dependientes.
• PatrÓN STATE
Se utiliza cuando el comportamiento de un objeto cambia dependiendo del
estado del mismo.
.. brindan una solución ya probada y documentada a problemas de desarrollo de software que están sujetos a contextos similares.
Los precedentes a los patrones de diseño vienen del campo de la Arquitectura, Christopher Alexander a finales de los 70 escribe varios libros acerca de urbanismo y construcción de edificios, y se plantea reutilizar diseños ya aplicados en otras construcciones que cataloga como modelos a seguir.
Un patrón es una descripción del problema y la esencia de su solución, q se puede reutilizar en casos distintos.
Es una solución adecuada a un problema común.
Efectivo resolviendo problemas similares en ocasiones anteriores.
que se haya podido comprobar su éxito resolviendo problemas anteriores
Reutilizable aplicable a diferentes problemas de diseño en distintas circunstancias.
es decir, podemos aplicarlo a problemas que se hallan en circunstancias similares a las descritas por el patrón.
Es aconsejable en el caso de tener el mismo problema o similar que soluciona el patrón
Un antipatrón de diseño es un patrón de diseño que conduce a una mala solución para un problema.
Resuelven problemas relacionados con la creación de instancias de objetos.
Se centran en problemas relacionados con la forma de estructurar las clases
Permiten resolver problemas relacionados con el comportamiento de la aplicación, normalmente en tiempo de ejecución.
INTERFACE
Ventajas Desacople entre comportamiento y clase.
Realización de clases “Utilities”
Se quiere enviar una petición a un objeto entre varios sin especificar explícitamente el receptor.
Este patrón puede ser utilizado cuando:
• La comunicación entre los conjuntos de objetos está bien definido y es complejo.
• Existen demasiadas relaciones y se necesita un punto común de control o comunicación