Los patrones de diseño describen soluciones probadas a problemas comunes en el desarrollo de software. Christopher Alexander definió un patrón como una solución a un problema particular que se puede utilizar repetidamente en diferentes contextos. Para ser considerada un patrón, una solución debe ser efectiva y reutilizable. El documento luego describe patrones fundamentales como Delegación, Interfaz, Singleton, Factory Method y otros, explicando sus problemas, soluciones y consecuencias.

1. PATRONES DE
DISEÑO
KELLY CUERVO

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.

6. • Creación
• Estructura
• Comportamiento

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

9. EJ: PATRÓN DELEGATION
PROBLEMA
• El lenguaje utilizado NO
PERMITE HERENCIA
MÚLTIPLE
• La clase C no desea
TODOS los métodos de B

10. EJ: PATRÓN DELEGATION
SOLUCION
• No se utiliza la
herencia sino que se
hace uso de la relación
“usa”

11. EJ: PATRÓN DELEGATION
IMPLEMENTACION
class C extends A {
B objB;
C ( ) { // En el constructor se puede crear obj. de B
objB=new B();
}
void b1( ) { objB.b1( );}
….

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.

19. MAS INFORMACION..
KELLY CUERVO
3164681006
DIEGO H. AGUILAR
SOFTWARE II
UNIVERSIDAD DE LA
AMAZONIA
2014