- Define una dependencia de uno-a-muchos entre objetos de forma que, cuando un objeto cambia de estado, se notifica a los objetos dependientes para que se actualicen automáticamente.
- También conocido como dependents, publish-subscribe.
Motivación
- Mantener la consistencia entre objetos relacionados, sin aumentar el acoplamiento entre clases
- Ej: separación de la capa de presentación en una interfaz de usuario de los datos de aplicación subyacentes.
Aplicabilidad
Usa el patrón Observer:
o Cuando una abstracción tiene dos aspectos, y uno depende del otro. Encapsular los aspectos en objetos distintos permite cambiarlos y reutilizarlos.
o Cuando cambiar un objeto implica cambiar otros, pero no sabemos exactamente cuántos hay que cambiar.
o Cuando un objeto debe ser capaz de notificar algo a otros sin hacer suposiciones sobre quiénes son dichos objetos. Esto es, cuando se quiere bajo acoplamiento.
Estructura.
Participantes
Subject:
o conoce a sus observadores, que pueden ser un número arbitrario.
o proporciona una interfaz para añadir y quitar objetos observadores
Observer:
o define la interfaz de los objetos a los que se deben notificar cambios en un sujeto
ConcreteSubject:
o almacena el estado de interés para sus observadores.
o envía notificaciones a sus observadores cuando su estado cambia
o define la interfaz de los objetos a los que se deben notificar cambios en un sujeto
ConcreteSubject:
o almacena el estado de interés para sus observadores.
o envía notificaciones a sus observadores cuando su estado cambia
ConcreteObserver:
o mantiene una referencia a un ConcreteSubject
o almacena el estado del sujeto que le resulta de interés
o implementa la interfaz de Observer para mantener su estado consistente con el del sujeto
Implementación
Correspondencia entre sujetos y observadores
o Usualmente, el sujeto guarda una referencia a sus observadores y esto resulta costoso si hay muchos sujetos y pocos observadores.
o mantiene una referencia a un ConcreteSubject
o almacena el estado del sujeto que le resulta de interés
o implementa la interfaz de Observer para mantener su estado consistente con el del sujeto
Implementación
Correspondencia entre sujetos y observadores
o Usualmente, el sujeto guarda una referencia a sus observadores y esto resulta costoso si hay muchos sujetos y pocos observadores.
¿Quién dispara la actualización llamando a notify?
o El sujeto desde aquellos métodos que cambian su estado.
§ ventaja: las clases cliente no tienen que hacer nada.
§ inconveniente: no es óptimo si hay varios cambios de estado seguidos.
o Las clases cliente.
§ ventaja: se puede optimizar llamando a notify tras varios cambios.
§ inconveniente: los clientes tienen la responsabilidad de llamar a notify.
Referencias perdidas a sujetos que se han eliminado.
o Se puede evitar notificando la eliminación del sujeto a sus observadores.
o En general, eliminar los observadores del sujeto eliminado no es una opción.
Observer en java.
§ ventaja: las clases cliente no tienen que hacer nada.
§ inconveniente: no es óptimo si hay varios cambios de estado seguidos.
o Las clases cliente.
§ ventaja: se puede optimizar llamando a notify tras varios cambios.
§ inconveniente: los clientes tienen la responsabilidad de llamar a notify.
Referencias perdidas a sujetos que se han eliminado.
o Se puede evitar notificando la eliminación del sujeto a sus observadores.
o En general, eliminar los observadores del sujeto eliminado no es una opción.
Observer en java.
No hay comentarios.:
Publicar un comentario