«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

Patrones de diseño I

¿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.

¿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.

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).

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.

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 elmodelo 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.

Ejemplo- MVC (Modelo Vista Controlador)

¿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.

¿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.

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.

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

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

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

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

Principios clave en el diseño depatrones 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

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

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

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); ...

} …

}

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); ...

} ... }

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); ...

} ... }

• 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 Bicyclea 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.

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:

Fábricas (Creacional)

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();

... } }

• Ahora las subclases pueden reutilizar createRace e incluso completeBicycle sin ninguna alteración:

Fábricas (Creacional)

//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);

} }

Fin parte I