The Observer Pattern defines a one-to-many dependency between objects, so that when one object change state, all of its depedents are notified and updated automatically.
When we talk about the observer pattern you can think of a newspaper and its subscribers, or an application that has to send notifications to their users. In both examples we can define each actor as subject(i.e: newspaper) and observers(i.e: subscribers).
Let's take for example an e-commerce platform, so when a user makes a purchase they receive a notification about the order. For example, I can go to my settings and check the checkboxes to receive a notification via Email, SMS and Phone Call. So, when I make a purchase, an order is created and then I receive a notification for each channel.
If we see the image above, we can see that the relationship between the subject and the observers is the one-to-many relationship that we defined earlier.
The subject is the object that contains the state, and the observers use that state, so when the data changes in the subject (the order) the observers are updated.
Now that we understand the definition of the Observer Pattern we can take a look at the class diagram.
The Observer pattern class diagram tell us that we need to have two interfaces (when we say interface we are referring to a contract, not a specific interface type, we can define either an abstract class or an interface type). One interface defines the methods that any subject needs to implement, and the other interface defines the methods that observers need to implement.
Also, the Subject interface Has-A (Filled arrow) observer interface. This means that the subject needs to have the observers list.
Finally, we have our concrete classes that implements our interfaces, so we have the ConcreteSubject and the ConcreteObserver (There could be many ConcreteObserver)
So, in the case of our example of the order and the notification channels we can have the following class diagram.
The Observer pattern provides an object design where subjects and observers are loosely coupled.
Because subject doesn’t depend on concrete classes but interfaces.
The only thing subject knows about an observer is that it implements an interface (The observer interface).
We don’t need to modify the subject to add new types of observers.
This pattern can have some variations, for example:
The way we register the observers (each observer could register themself via constructor or we could have an array to register all observers to the subject).
The way we get the data from the subject (subject can push the data to the observer or the observer can pull the data from the subject).
In conclusion, the whole idea of this pattern is to communicate a state to a group of objects in a loosely coupled way.
Follow me on: Twitter