Patrones de Diseño

Patrones de Diseño: OBSERVADOR
DEFINICION:
Observador (en inglés: Observer) es un patrón de diseño que 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. Se trata de un patrón de comportamiento (existen de 3 tipos: Creación, Estructurales y de Comportamiento), es decir, estárelacionado con algoritmos de funcionamiento y asignación de responsabilidades a clases y objetos. Los patrones de comportamiento describen no solamente estructuras de relación entre objetos o clases sino también esquemas de comunicación entre ellos y se pueden clasificar en función de que trabajen con clases (Método Plantilla) u objetos (Cadena de Responsabilidad, Comando, Iterador, Recuerdo,Observador, Estado, Estrategia, Visitante).
ESTRUCTURA:
















IMPLEMENTACION:
Opción 1:
Para evitar que el observador concreto tenga una asociación con el sujeto concreto, podríamos hacer que la relación entre sujeto y observador fuese bidireccional, evitando así asociaciones concretas, el problema es que dejaría de ser una interfaz. El que deje de ser una interfaz puedeproducir problemas si el lenguaje de programación no soporta la herencia múltiple.
Se podría eliminar la bidireccionalidad de la asociación pasando el sujeto como parámetro al método actualizar y ya no tendríamos que referenciar el objeto observado. Esto podría causar problemas si observamos varios objetos, tanto de la misma clase como de distintas, ya que no elimina dependencias, y para haceroperaciones específicas sobre el objeto actualizado nos obliga a hacer en la implementación.
Opción 2:
Si hay muchos sujetos sin observador, la estructura de los observadores está desaprovechada, para solucionarlo podemos tener un intermediario que centralice el almacenamiento de la asociación de cada sujeto con sus observadores. Para esta solución creamos ese gestor de observadores usando elpatrón Singleton(Instancia única), ya que nos proporciona una única referencia y no una por cada sujeto. El gestor aunque mejora el aprovechamiento del espacio, hace que se reduzca el rendimiento y se pierde eficiencia en el método notificar.
Opción 3:
El responsable de iniciar la comunicación es el sujeto concreto, pero se puede dar un problema cuando el objeto concreto está siendo actualizado de formacontinua ya que debido a esto tendríamos que realizar muchas actualizaciones en muy poco tiempo. La solución sería suspender temporalmente las llamadas al método de actualización/notificación; por ejemplo, haciendo que el cliente pueda activar o desactivar las notificaciones y notificar todos los cambios cuando las vuelva a habilitar. El patrón Estado sería una posible solución para diseñar estavariante de no notificar si no se han dado cambios o hacerlo en caso de que si.
Opción 4 (Referencias inválidas):
A la hora de implementar este patrón debemos de ser cuidadosos cuando un elemento observable desaparece. En ciertos lenguajes será el gestor de memoria el que cada cierto tiempo debe de limpiará las referencias liberadas, pero si un observable que sigue siendo observado puede noliberarse nunca. Para solucionar este problema puede crearse una función “destruir (destroy) ” que notifique al gestor que el elemento observable va a desaparecer y si no estamos usando la variante del gestor el observable directamente des-registrará a sus observadores. Antes de esto hay que eliminar las referencias a este elemento, por tanto, hay que eliminar a los observadores antes de eliminar alobservable, ya que así evitaremos tanto que aparezcan referencias inválidas al objeto una vez éste haya sido eliminado, como que se produzcan operaciones inválidas intentando invocarlo.
Podemos avisar a los observadores creando un método actualizar especial, en el que tendríamos dos opciones:
1. El observador también muere.
2. El observador sigue vivo, pero apunta a nulo.
Opción 5:
Ya que...