Definir una dependencia de 1:n de forma que cuando el objeto 1 cambie su estado, los n objetos sean avisados y se actualicen automáticamente.

Supongamos que tenemos un o unos objetos dependientes de otro. Por ejemplo, supongamos que una ventana o applet depende de los componentes gráficos que reciben eventos (clic en botón, etc.). Otro caso, típico del patrón, es tener diversas vistas de una fuente de datos, de tal forma que si cambia la fuente, entonces las vistas se actualicen automáticamente.

El observador no es un mediador entre los sujetos (objetos que cambian de estado) y los objetos dependientes, ya que el mismo es un objeto dependiente. El observador recibe la orden de actualizarse por parte del sujeto "dominante"

Interesante cuando un cambio en un objeto implique cambios en otros y no se sepa cuantos objetos necesitan cambiar. Como se puede observar en el siguiente diagrama el sujeto tiene un método notify() que se encarga de mandar el mensaje de update() a todos los observadores.

Permite la división de un sistema en niveles. Además de permitir reusar sujetos y observadores por separado.

Una extensión natural de este patrón es hacer mezcla del patrón mediador y del patrón observador, de tal forma que los avisos de cambios que mandamos al observador sean notificados a otros objetos dependientes. El observador recibe un mensaje de cambio de estado y notifica a los objetos dependientes que se actualicen. Dicho de otra forma, cuando las relaciones de dependencia entre Subject y Observer son complicadas conviene encapsular la semántica de actualización en una clase ManejadorCambio(Mediador).

Es posible que un observer esté ligado a más de un subject: la operación update tendrá como argumento el subject.¿Quién dispara la notificación?

• Métodos set en la clase Subject
• Clientes de la clase Subject

Asegurarse de notificar siendo el estado de Subject consistente. Al registrar un observer es posible asociarle el evento sobre el que quiere ser notificado:

		attach(Observer obs, Evento interes);

Java 1.1 introdujo un nuevo modelo de eventos para GUI basado en el patrón Observer.

• Componentes GUI que pueden generar eventos son llamados fuentes de eventos (event sources).
• Objetos que desean ser notificados de eventos GUI son llamados oyentes de eventos (event listeners). Estos oyentes en Java trabajan como observers de nuestro patrón.
• Los listeners deben registrarse en las fuentes (componentes GUI).

El orden sería "componente_GUI --->Listener ---> Objeto_dependiente (un applet, por ejemplo)

Un ejemplo en Java, extraido de una clase applet, donde al botón le añadimos un listener:

     boton_crear.addActionListener(new ap_robot_boton_actionAdapter(this));

Lo primero es que el listener (ap_robot_boton_actionAdapter) se registra en el componente GUI (en este caso boton_crear de la clase Button) por medio de una llamada a addItemListener(). En segundo lugar, cuando se produce un evento el componente lo notifica al listener y este manda un mensaje al applet (en nuestro caso a boton_crear_actionPerformed(ActionEvent e), para que realice las acciones oportunas:

  void boton_crear_actionPerformed(ActionEvent e) {

    ...

  }

Obsérvese que el evento queda encapsulado por la clase ItemEvent.