The Observer Pattern uses two abstract classes or interfaces:
Observer and
Observed (also called Subject).
The Observer Pattern is used when there is a "one to many relationship between objects" such as if one object is modified,
its depenedent objects are to be notified automatically. The diagram below illustrates the structure:
The graphic illustrates a class diagram implementing the Observer Design Pattern. Here is a detailed description:
Key Components:
Observed (Subject):
Represents the subject in the Observer Pattern.
Contains a collection of observers (theObservers) to maintain the list of objects interested in being notified of changes.
Attributes:
theObservers : Observer[]: A collection or list of Observer instances.
Methods:
+addObserver(o: Observer): void: Adds an observer to the list.
+removeObserver(o: Observer): void: Removes an observer from the list.
+notifyObservers(): void: Notifies all registered observers of a state change.
Observer (Interface):
Defines the contract for observer objects.
Methods:
+update(): A method to be implemented by concrete observers, which will be called when the subject notifies its observers.
ConcreteObserved (Concrete Subject):
A concrete implementation of the Observed class.
Contains the state that observers are interested in.
Attributes:
state: Represents the internal state of the subject.
Methods:
+getState(): A method to retrieve the current state.
+changeState(): A method to modify the state and notify observers of the change.
Concrete Observer:
Implements the Observer interface.
Responds to notifications sent by the subject when its state changes.
The diagram shows a placeholder Observer instance with the +update() method for concrete implementations.
Relationships:
Observed → Observer:
The subject (Observed) depends on the Observer interface, enabling any class implementing Observer to register as a listener.
ConcreteObserved inherits from Observed:
The ConcreteObserved class extends the functionality of the Observed class by adding state-specific logic.
Observer Implementation:
Concrete classes implementing Observer are required to implement the update() method, ensuring they can respond to notifications.
Purpose: The diagram demonstrates how the "Observer Design Pattern" decouples the subject (the object being observed) from the observers (objects interested in updates). The pattern ensures flexibility, as observers can dynamically register, deregister, or respond to state changes in the subject.
Each Observer object possesses an update() method which is invoked by the Observed object when the Observed object changes
The Observer pattern is also responsible for telling the Observed object that it should notify the Observer object when it changes
Structure of the Observer Pattern
Observer pattern consisting of Observed, Observer, and ConcreteObserved
Each Observer object possesses an update() method which is invoked by the Observed object when the Observed object changes.
The Observer pattern is also responsible for telling the Observed object that it should notify the Observer object when it changes.
Use the Observer pattern in any of the following situations:
When an abstraction has two aspects, one dependent on the other. Encapsulating these aspects in separate objects lets you vary and reuse them independently.
When a change to one object requires changing others, and you don't know how many objects need to be changed.
When an object should be able to notify other objects without making assumptions about who these objects are. In other words, you don't want these objects tightly coupled.
Observer Pattern as Alternative to MVC
You might think of the Observer pattern as an alternative to the MVC Pattern. At the root of the Observer Pattern are Subject and Observer interfaces.
The Subject holds a given state and
the observers subscribe to the subject to be informed of the current state.
You can think of it as a blog with many subscribers, where one set of information is routinely updated for a variety of users who subscribe or regularly read the blog. Each time the blog is updated (its state changes) and all of the subscribers are informed. Figure 14-1 shows the Observer class diagram.
Figure 6-6: Observer class diagram
One of the more interesting and possibly perplexing features of this pattern is the methods of the Subject. While the italicized title "Subject" title indicates an interface (an abstract class in this case), abstract methods are italicized as well.
However, as you can see in Figure 6-6, none of the methods are italicized. It is clear
which methods Subject generates, and
the Notify() method even has pseudocode to help out.
You will find several different implementations of the Observer pattern.
Observed Object
The Observed object must keep a list of the objects observing it. It must provide an interface for adding objects to and removing objects from that list. Finally, it contains the necessary methods that result in changes to its state. Every time the Observed state of the object changes, it cycles through the list, notifying each Observer in turn of the change. The Observer interface declares the update method that the Observed object will invoke. This method does whatever the class wants to do as a result of the notification.
Observer interface in java.util
The java.util package actually has an interface (or abstract class) called Observer and a class called Observable. However, neither is much used, even though the delegation event model used in Java 1.1 makes heavy use of the Observer pattern. The reason is that java.util.Observable is a class rather than an interface. To use these two predefined bits of code your Observed object must extend Observable. In Java's single inheritance hierarchy, this is a huge impediment. This is one case where the abstract nature of the main classes is essential.
public interface Observer:
A class can implement the Observer interface when it wants to be informed of changes in observable objects. After applying the Observer pattern, different observers can be added dynamically without requiring any changes to the Subject class. Similarly, observers remain unaffected when the state change logic of the subject changes. The Observer pattern is useful for designing a consistent communication model between a set of dependent objects and an object that they are dependent on. This allows the dependent objects to have their state synchronized with the object that they are dependent on. The set of dependent objects are referred to as observers and the object that they are dependent on is referred to as the subject. In order to accomplish this, the Observer pattern suggests a publisher-subscriber model leading to a clear boundary between
the set of Observer objects and
the Subject object.
MVC within the context of Observer
In the (MVC) model-view-controller architecture the model is the real thing, and the views approximate it. Think instead of a model that poses for a painting. The model is real, and different artists can observe the same model and draw different views. Here is what happens when a user types text into one of the windows:
The controller tells the model to insert the text that the user typed.
The model notifies all views of a change in the model.
All views repaint themselves.
During painting, each view asks the model for the current text.
This architecture minimizes the coupling between the 1) model, 2) views, and 3) controllers. The model knows nothing about the views, except that they need to be notified of all changes. The views know nothing of the controllers and it is easy to add more views to a model. It is also easy to change the controller of a view, for example to facilitate voice input. Let us have a closer look at the notification mechanism.
The model knows about a number of observers, namely, the views.
An observer is an object that is interested in state changes of the model.
The model knows nothing in detail about the observers except that it should notify them whenever the model data changes.
Observed Object - Exercise
In this exercise, you will write a TimeObserver interface for the course project.
Observed Object - Exercise
