Clase 1

1. Patrones de diseño I
«Promoviendo buenas prácticas de diseño y
construcción de software»
Profesor: Juan José González Faúndez
Curso: Arquitectura y patrones J2EE
UNAB 2011

2. ¿Qué es un patrón?
• Cuando los expertos trabajan en un problema en
particular, es muy raro que se trabaje o invente
una solución que es completamente distinta a las
ya existentes. A menudo es posible recordar un
problema que ya había sido solucionado por otra
persona; la reutilización de la esencia de la
solución a este problema se utiliza como solución
para resolver el nuevo problema. Es decir, la
solución al problema es común al dominio del
problema, como la arquitectura por ejemplo.

3. ¿Qué es un patrón?
• El arquitecto Christopher Alexander define el término
patrón de la siguiente forma:
Cada patrón es una regla compuesta de tres partes,
que expresa una relación entre un determinado
contexto, un problema, y una solución.
Los patrones de diseño son la base para la búsqueda de
soluciones a problemas comunes en el desarrollo
de software y otros ámbitos referentes al diseño de
interacción o interfaces.

4. Ejemplo- MVC (Modelo Vista Controlador)
• Consideramos el uso de este patrón cuando
desarrollamos un software que tiene una
interface humano-computador.
– Las interfaces de usuario están propensas a solicitudes
de cambio.
– Por ejemplo, cuando se extiende la funcionalidad de
una aplicación, el menú tiene nuevas funciones, y la
interface de usuario podrían ser adaptada para
clientes específicos, por ejemplo, el cambio de una
aplicación windows (Java Application, Winform, etc) a
una aplicación web (JSP, ASP.NET, etc).

5. Ejemplo- MVC (Modelo Vista Controlador)
• Para resolver este problema, dividimos la aplicación en
3 áreas:
– El modelo, es quien encapsula el núcleo de la información
y la funcionalidad, es independiente de las
representaciones de salida o comportamientos de entrada
(events).
– Las vistas, quienes son responsables de mostrar la
información al usuario. Múltiples vistas pueden estar
asociadas al modelo.
– Cada vista, tiene un controlador asociado, quienes reciben
la entrada, usualmente a través de eventos (click en un
botón por ejemplo o entrada por teclado). Estos eventos
son traducidos a peticiones de servicios (request services)
las cuales se envían a cada modelo o a la vista.

6. Ejemplo- MVC (Modelo Vista Controlador)
• La separación del modelo de la vista y los
componentes del controlador permite múltiples
vistas del mismo modelo. Si el usuario cambia el
modelo a través del controlador de una vista, todas
las vistas dependientes de esta información, deben
reflejar el cambio. Para lograr esto, el modelo notifica
a todos las vista cada vez que hay cambios de
datos. Las vistas a su vez recuperan los datos nuevos
del modelo y actualizan la información mostrada.

7. Ejemplo- MVC (Modelo Vista Controlador)

8. ¿Qué hace un patrón?
• Un patrón de arquitectura de software describe un diseño
particular a un problema recurrente que se plantea en
contextos específicos de diseño, y presenta un sistema
general, bien probado para su solución. El esquema de
solución es especificado mediante la descripción de sus
elementos constitutivos, sus responsabilidades, las relaciones,
y las formas en que estos colaboran.

9. ¿Qué hace un patrón?
Contexto: una situación que da lugar a un problema.
Problema: el problema recurrente que se plantean en ese contexto.
Solución: una solución probada del problema.

10. Categorías de patrones
• Patrones de creación
– Tienen que ver con la creación, inicialización y
configuración de clases y objetos
• Patrones estructurales
– Tiene que ver con el desacoplo entre la interfaz y
la implementación de clases y objetos
• Patrones de comportamiento
– Tiene que ver con las interacciones dinámicas
entre sociedades de clases y objetos.

11. Patrones de creación
• Factory Method
– Permite que sean las clases derivadas las que creen
objetos
• Abstract Factory
– Interfaz para crear familias de objetos sin especificar sus
clases
• Builder
– Permite crear objetos complejos incrementalmente
• Prototype
– Permite clonar instancias a partir de un prototipo
• Singleton
– Asegura que una clase sólo tiene una única instancia

12. Patrones estructurales
• Adapter
– Traductor que adapta la interfaz de un servidor a un cliente
• Bridge
– Abstracción que vincula a una entre muchas implementaciones
• Composite
– Estructura para construir jerarquías basadas en composición
• Decorator
– Extender la funcionalidad dinámicamente de modo transparente
• Facade
– Definir una interfaz unificada para varios subsistemas
• Flyweight
– Compartición eficiente de muchos objetos de grano fino
• Proxy
– Proporciona un sustituto de otro objeto para controlar su acceso

13. Patrones de comportamiento (1/2)
• Chain of Responsability
– Solicitud delegada al responsable de proporcionar un servicio
• Command
– Encapsular una solicitud como un objeto
• Interpreter
– Intérprete y representación de la gramática de un lenguaje
• Iterator
– Modo de acceso secuencial a elementos agregados a un objeto
• Mediator
– Encapsular la interacción entre objetos (que no sea explícita)
• Memento
– Capturar el estado interno de un objeto para restaurarlo luego

14. Patrones de comportamiento (2/2)
• Observer
– Los objetos dependientes se actualizan cuando cambia un
sujeto
• State
– Objeto cuyo comportamiento depende de su estado
• Strategy
– Abstracción para seleccionar un algoritmo entre varios
• Template Method
– Definir un algoritmo base diferiendo ciertos pasos a
subclases
• Visitor
– Aplicar operaciones a elementos de objetos heterogéneos

15. Principios clave en el diseño de
patrones y frameworks
• Separar la interfaz de la implementación
• Según los objetivos, determinar lo que es común
(estable) y lo que varía con la interfaz y con la
implementación
– Si hay poca variabilidad, es difícil adaptar los componentes
del framework a los casos concretos
– Si hay poco común, es difícil que los usuarios comprendan
y confíen en el comportamiento del framework
• Permitir la sustitución de implementaciones variables
utilizando una interfaz común
– En frameworks la distinción entre lo común y lo variable se
suele implementar mediante template methods y callbacks

16. Uso de patrones de diseño
• Ventajas:
– Reutilizan (y documentan) arquitecturas software
– Capturan y hacen accesible el conocimiento experimentado y
los pros y los contras (tradeoffs ) que aparecen en el diseño
– Ayudan a mejorar la comunicación entre desarrolladores
– Facilitan la transición hacia la tecnología orientada a objetos
• Desventajas:
– No llevan a la reutilización directa del código
– Los equipos pueden padecer una sobrecarga de patrones
– Se validan con la experiencia y no con tests automáticos
– Su integración en el proceso de desarrollo no es automatizable

17. Diseño de patrones de diseño
• No reconvertir todo en patrones, sino que es
mejor desarrollar patrones para el dominio y
reutilizar tácticos
• Institucionalizar recompensas por el desarrollo de
patrones
• Involucrar a los desarrolladores de patrones con
desarrolladores de aplicaciones y los expertos en
dominio
• Documentar claramente la aplicabilidad de los
patrones
• Tener mucho cuidado con las expectativas

18. Fábricas (Creacional)
• Suponga que está escribiendo una clase para representar
carreras de bicicletas. Una carrera se compone de muchas
bicicletas (entre otros objetos, quizás).
class Race {
Race createRace() {
Frame frame1 = new Frame();
Wheel frontWhee11 = new Wheel();
Wheel rearWhee11 = new Wheel();
Bicycle bike1 = new Bicycle(frame1, frontWhee11, rearWhee11);
Frame frame2 = new Frame();
Wheel frontWhee12 = new Wheel();
Wheel rearWhee12 = new Wheel();
Bicycle bike2 = new Bicycle(frame2, frontWhee12, rearWhee12);
...
}
…
}

19. Fábricas (Creacional)
• Puede especificar la clase Race para otras
carreras de bicicleta.
// carrera francesa
class TourDeFrance extends Race {
Race createRace() {
Frame frame1 = new RacingFrame();
Wheel frontWhee11 = new Whee1700c();
Wheel rearWhee11 = new Whee1700c();
Bicycle bike1 = new Bicycle(frame1, frontWhee11, rearWhee11);
Frame frame2 = new RacingFrame();
Wheel frontWhee12 = new Whee1700c();
Wheel rearWhee12 = new Whee1700c();
Bicycle bike2 = new Bicycle(frame2, frontWhee12, rearWhee12);
...
}
...
}

20. Fábricas (Creacional)
//carrera en tierra
class Cyclocross extends Race {
Race createRace() {
Frame frame1 = new MountainFrame();
Wheel frontWhee11 = new Whee127in();
Wheel rearWhee11 = new Whee127in();
Bicycle bike1 = new Bicycle(frame1, frontWhee11, rearWhee11);
Frame frame2 = new MountainFrame();
Wheel frontWhee12 = new Whee127in();
Wheel rearWhee12 = new Whee127in();
Bicycle bike2 = new Bicycle(frame2, frontWhee12, rearWhee12);
...
}
...
}

21. Fábricas (Creacional)
• En las subclases, createRace devuelve un objeto Race porque
el compilador Java impone que los métodos superpuestos
tengan valores de retorno idénticos.
• Por economía de espacio, los fragmentos de código anteriores
omiten muchos otros métodos relacionados con las carreras
de bicicleta, algunos de los cuales aparecen en todas las
clases, en tanto que otros aparecen sólo en ciertas clases.
• La repetición del código es tediosa y, en particular, no fuimos
capaces de reutilizar el método Race.createRace. (Podemos
observar la abstracción de creación de un único objeto Bicycle
a través de una función; utilizaremos esta sin más discusión,
como es obvio. Debe existir un método mejor. El patrón de
diseño de fábrica nos proporciona la respuesta.

22. Fábricas (Creacional)
• Un método de fábrica es el que fabrica objetos de un tipo
determinado. Podemos añadir métodos de fábrica a Race:
class Race {
Frame createFrame() { return new Frame(); }
Wheel createWheel() { return new Wheel(); }
Bicycle createBicycle(Frame frame, Wheel front, Wheel rear) {
return new Bicycle(frame, front, rear);
}
// devuelve una bicicleta completa sin necesidad de ningún argumento
Bicycle completeBicycle() {
Frame frame = createFrame();
Wheel frontWheel = createWheel();
Wheel rearWheel = createWheel();
return createBicycle(frame, frontWheel, rearWheel);
}
Race createRace() {
Bicycle bike1 = completeBicycle();
Bicycle bike2 = completeBicycle();
...
}
}

23. Fábricas (Creacional)
• Ahora las subclases pueden reutilizar
createRace e incluso completeBicycle sin
ninguna alteración:

24. //carrera francesa
class TourDeFrance extends Race {
Frame createFrame() { return new RacingFrame(); }
Wheel createWheel() { return new Whee1700c(); }
Bicycle createBicycle(Frame frame, Wheel front, Wheel rear) {
return new RacingBicycle(frame, front, rear);
}
}
class Cyclocross extends Race {
Frame createFrame() { return new MountainFrame(); }
Wheel createWheel() { return new Whee126inch(); }
Bicycle createBicycle(Frame frame, Wheel front, Wheel rear) {
return new RacingBicycle(frame, front, rear);
}
}

25. Fin parte I