Se describe el patrón de diseño observer, con un diagrama de ejemplo como se hace.

1. Observer: Patrón de diseño
Alberto Rodríguez Villalobos
Ingeniería en Software 2

2. Este patrón define una relación uno a muchos, entre un grupo de objetos. Cuando un
objeto cambia su estado, todos sus dependientes son notificados y actualizados
automáticamente.
Otros nombres: Dependents, Publish-Suscribe

3. Descripción
 Los objetos claves son “Subject” y “Observer”.
 La motivación de este patrón es la reutilización.
 Puede no haber relación directa entre objetos.
 El tipo de interacción es conocida como Publicar-Suscribir.
 El subject es publicador de notificaciones.
 Cualquier número de observers puedes suscribirse para recibir notificaciones.

4. Colaboradores
 Subject:
-Conoce sus Observers. Cualquier número de observes pueden observar a Subject.
-Provee una interfaz para adjuntar y separar objetos Observer.
 Observer:
-Define una interfaz de actualización para los objetos Observer que deben ser notificados de los cambios en el Subject.
 Concrete_Subject:
-Almacena estados de interés para los objetos Concrete_Observer.
-Envía una notificación a sus Observers cuando el estado cambia.
 Concrete_Observer:
-Mantiene referencia de objetos Concrete_Subject.
-Almacena los estados que deben ser consistentes con los Subject.
-Implementa la actualización del Observer.

6. Aplicabilidad
 Cuando una abstracción tiene 2 aspectos o más, uno dependiente del otro.
 Cuando un objeto requiere el cambio de otros, y no se sabe cuántos objetos
necesitan ser cambiados.
 Cuando un objeto debe notificar a otros objetos sin estimar cuantos son estos.

7. Ventajas y desventajas
 EL patrón Observer permite variar los sujetos y los observadores independientemente. Se puede rehusar
sujetos sin el rehúso de observadores y viceversa.
 Permite agregar observadores sin modificar el sujeto o los observadores.
 Acoplamiento abstracto entre Subject y Observer. Todo lo que un objeto sabe de sus observadores es que
tiene una lista de objetos que satisfacen la interfaz Observer. Con lo que podrían incluso pertenecer a dos
capas distintas de la arquitectura de la aplicación.
 No se especifica el receptor de una actualización. Se envía a todos los objetos interesados
 Actualizaciones inesperadas. Se podrían producir actualizaciones en cascada muy ineficientes.