PATRONES DE DISEÑO
sábado, 9 de agosto de 2014
domingo, 7 de julio de 2013
PATRÓN OBSERVADOR (OBSERVER)
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).
La
variación de la encapsulación es la base de muchos patrones de comportamiento,
por lo que cuando un aspecto de un programa cambia frecuentemente, estos
patrones definen un objeto que encapsula dicho aspecto. Los patrones definen
una clase abstracta que describe la encapsulación del objeto.
Este
patrón también se conoce como el patrón de publicación-inscripción o modelo-patrón.
Estos nombres sugieren las ideas básicas del patrón, que son: el objeto de
datos, que se le puede llamar Sujeto a partir de ahora, contiene
atributos mediante los cuales cualquier objeto Observador o vista se
puede suscribir a él pasándole una referencia a sí mismo. El Sujeto
mantiene así una lista de las referencias a sus observadores. Los observadores
a su vez están obligados a implementar unos métodos determinados mediante los
cuales el Sujeto es capaz de notificar a sus observadores suscritos los
cambios que sufre para que todos ellos tengan la oportunidad de refrescar el
contenido representado. De manera que cuando se produce un cambio en el Sujeto,
ejecutado, por ejemplo, por alguno de los observadores, el objeto de datos
puede recorrer la lista de observadores avisando a cada uno. Este patrón suele
observarse en los frameworks de interfaces gráficas orientados a objetos, en
los que la forma de capturar los eventos es suscribir listeners a los
objetos que pueden disparar eventos.
El
patrón Observer es la clave del patrón de arquitectura Modelo Vista
Controlador (MVC). De hecho el patrón fue implementado por primera vez en Smalltalk's
MVC basado en un framework de interfaz. Este patrón está implementado en
numerosos librerías y sistemas, incluyendo todos los toolkits de GUI.
Objetivo
Definir
una dependencia uno-a-muchos entre objetos, de tal forma que cuando el objeto
cambie de estado, todos sus objetos dependientes sean notificados
automáticamente. Se trata de desacoplar la clase de los objetos clientes del
objeto, aumentando la modularidad del lenguaje, creando las mínimas
dependencias y evitando bucles de actualización (espera activa o polling). En
definitiva, normalmente, usaremos el patrón Observador cuando un elemento
“quiere” estar pendiente de otro, sin tener que estar encuestando de forma
permanente si éste ha cambiado o no.
Motivación
Si se
necesita consistencia entre clases relacionadas, pero con independecia, es
decir, con un bajo acoplamiento.
Aplicabilidad
Puede
pensarse en aplicar este patrón cuando una modificación en el estado de un
objeto requiere cambios de otros, y no deseamos que se conozca el número de
objetos que deben ser cambiados. También cuando queremos que un objeto sea
capaz de notificar a otros objetos sin hacer ninguna suposición acerca de los
objetos notificados y cuando una abstracción tiene dos aspectos diferentes, que
dependen uno del otro; si encapsulamos estos aspectos en objetos separados
permitiremos su variación y reutilización de modo independiente.
Estructura
Subject: Conoce a sus observadores, Proporciona una
Interfaz para que se suscriban los objetos Observer.
Observer: Define una interfaz para actualizar los objetos que deben ser notificados de cambios en el objeto Subject.
ConcreteSubject: Guarda el estado de interes para los objetos ConcreteObserver, Envia una notificacion a sus observadores cuando cambia su estado.
ConcreteObserver: Mantiene una referencia a un objeto ConcreteSubject, Guarda el estado que deberia permanecer sincronizado con el objeto observado, Implementa la interfaz Observer para mantener su estado consistente con el objeto observado.
Colaboraciones:
El objeto observado notifica a sus observadores cada vez que ocurre un cambio.
Después de ser informado de un cambio en el objeto observado, cada observador concreto puede pedirle la información que necesita para reconciliar su estado con el de aquél
Observer: Define una interfaz para actualizar los objetos que deben ser notificados de cambios en el objeto Subject.
ConcreteSubject: Guarda el estado de interes para los objetos ConcreteObserver, Envia una notificacion a sus observadores cuando cambia su estado.
ConcreteObserver: Mantiene una referencia a un objeto ConcreteSubject, Guarda el estado que deberia permanecer sincronizado con el objeto observado, Implementa la interfaz Observer para mantener su estado consistente con el objeto observado.
Colaboraciones:
El objeto observado notifica a sus observadores cada vez que ocurre un cambio.
Después de ser informado de un cambio en el objeto observado, cada observador concreto puede pedirle la información que necesita para reconciliar su estado con el de aquél
Consecuencias
Las
consecuencias de aplicar este patrón pueden ser tanto beneficiosas como pueden
perjudicar algunos aspectos. Por una parte abstrae el acoplamiento entre el
sujeto y el observador, lo cual es beneficioso ya que conseguimos una mayor
independencia y además el sujeto no necesita especificar los observadores
afectados por un cambio. Por otro lado, con el uso de este patrón ocurre que
vamos a desconocer las consecuencias de una actualización, lo cual, dependiendo
del problema, puede afectarnos en mayor o menor medida (por ejemplo, al
rendimiento).
Suscribirse a:
Entradas (Atom)