Clase del 9/10/2007 (Diseño Avanzado con Objetos)

Mediator

Intent

Define un objeto que encapsula cómo interactuan una serie de objetos. Promueve un bajo acoplamiento al evitar que los objetos se refieran unos a otros explícitamente, y permite variar la interacción entre ellos en forma independiente.

Resumen

Cuando hay comportamiento divido entre muchos objetos que deben interactuar entre si, esto puede hacer que los objetos sean menos reutilizables debido a su alto acoplamiento con otros objetos. Ademas cambiar ese comportamiente para una clase, puede derivar en muchas subclases. Estos problemas se pueden evitar encapsulando el comportamiento colectivo en un nuevo objeto (mediador). Este, es responsable de coordinar y controlar las interacciones entre un grupo de objetos. Los objetos solo conocen al mediador reduciendo así el acoplamiento preexistente. El comportamiento es mas facil de modificar ya que esta encapsulado en un solo objeto y ademas puede extenderse mediante sbuclasificación de la clase.

Consecuencias

Reduce la herencia porque todo el comportamiento que se deberia extender por herencia en muchas clases si el comportamiento estuviera distribuido esta en un solo lugar.

Desacopla gran parte del acoplamiento entre muchos objetos.

Simplifica protocolo porque los objetos solo conocen el protocolo de un mediador y no el de un monton de otros objetos.

Abstrae como cooperan los objetos.

Al centralizar el control, el mediador, puede quedar un objeto demasiado complejo.

Facade

Intent

Proporciona una interfaz unificada para un conjunto de interfaces de subsistemas. Define una interfaz de alto nivel que hace que los subsistemas sean más fáciles de usar.

Resumen

La fachada proporciona una interfaz única y simplificada para los servicios mas generales de los subsistemas de una sistema. De este modo si tenes subsistemas complejos, los clientes que no necesiten usar toda la complejidad tiene una interfaz simple para las peticiones mas recurrentes. La fachada no oculta la funcionalidad de más bajo nivel para aquellos que la necesiten.

Consecuencias

Oculta a los clientes los componentes del subsistema, reduciendo así el número de objetos con los que tratan y haciendo el subsistema más fácil de usar.

Desacopla los clientes con los subsistemas. Este permite mayor flexibilidad al cambio y ayuda a estructurar el sistema en capas.

No impide que las aplicaciones usen las clases del subsitema en caso de que sea necesario. De este modo se puede elegir entre facilidad de uso y generalidad.

Composite

Intent

Compone objetos en estructuras de árbol para representar jerarquías de parte-todo. Permite que los clientes traten de manera uniforme a los objetos individuales y a los compuestos.

Resumen

La clave del patrón Compsite es una clase abstracta que representa tanto a primitivas como a sus contenedoras. De esta manera se representan estructuras arboreas, con elementos primitivos, de cualquier granularidad y para el cliente es transparente si esta trabajando con elementos primitivos o contenedores. Es uno de los patrones mas usado.

Consecuencias

Donde el código esepre un objeto primitivo, también podrá recibir un objeto compuesto.

Simplifica al cliente quienes no conocen si trabajan con hojas o con estructuras compuestas.

Se pueden añadir nuevos componentes de manera muy simple.

Puede llegar a ser demasiado general. Si necesitaramos ciertas restricciones sobre los componentes de cierto compuesto esto es demasiado complejo.

Implementación

Se pueden mantener referencias explicitas al padre para simplificar recorrido.

Donde se pone el protocolo de manejo de hijos? En la clase abstracta y se genera un error cuando se llama el mensaje sobre un primitivo? o directamente en la subclase compuesto?

Puede pasar que necesitemos cierto orden sobre los elementos del compuesto.

Observer

Intent

Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambie de estado se notifique y se actualicen automáticamente todos los objetos que dependen de él.

Resumen

El ejemplo clásico es el del Model View Controller donde elementos de las distintas posibles vistas dependen de un mismo elemento de modelo. El patrón Observer describe cómo establecer estas relaciones. Los principales objetos de este patrón son el sujeto y los observadores. Un sujeto cambia su estado y notifica a los observadores quienes en respuesta consultarán al sujeto para sincronizar su estado con este.

Consecuencias

Los distintos sujetos y observadores estan bastante desacoplados y se pueden modificar independientemente.

Se pueden añadir y quitar observadores en cualquier momento.

Se puede armar cierto problema cuando hay muchos observadores y se reciben notificaciones de cambio constantemente que para algunos observadores son insignificantes.

Implementación

Una cuestión importante es quien dispara la actualización.

Lo puede hacer el sujeto cuando cambia de estado. La ventaja es que es transparente para los clientes y la desventaja que una llamada que involucre mas de una operación puede causar varias actualizaciones consecutivas. Si, en cambio, lo hacen los clientes la ventaja es que lo haran solo cuando se realizó una vez que se hicieron los cambios de estado juntos, pero los clientes tienen esa responsabilidad demasiado importante y esto puede ser causa de errores.

Finalmente la dicotomia entre el push y el pull. Si el sujeto envía información importante acerca del cambio a sus observadores (push) o si los observadores deben pedir esa información. El push es menos reutilizable y el pull puede ser mas infeciente.