The Observer Pattern

The Observer Pattern — defines a one-to-many relationship between objects so that one object changes state, all of its dependents are notified and updated automatically.

Do you read newspaper? If yes, you will probably know about the observer pattern. If no, no worries, I will explain it.

Let’s ask yourself a simple question. What should you do in order to get the daily newspaper at home? Well, the answer is simple. You have to go the newspaper publisher and register/subscribe with them. The next day onwards, you will get the newspaper daily until you unregister yourself. Well, you just learned the observer pattern. It is the combination of the publisher and the subscribers where each subscriber has to register with a publisher in order to get the periodic updates from the publisher. We can define it as follows:

Publisher + Subscribers = The Observer Pattern

To better understand it, lets design a weather monitoring app which will display weather condition(current condition, statistics, and a simple forecast).

Assumption

1. We are having a weather station which will provide the weather related data in real time

What would be first step here? It would be to figure out all the entities or components that will be connected together to display weather information.

Entities

1. Weather Data [Publisher/Subject]: It would be the publisher. Let’s call it a subject which will register all observers and publish the weather information to all registered observers when there is a change in its state i.e. temperature, humidity, and pressure.
2. CurrentConditionDisplay[Observer]: It would be the observer and will subscribe it to the subject. Similarly, there would be StatisticDisplay and ForecastDisplay.

By applying the design principles discussed in the previous article and the observer pattern, we can design the solution as follows:

We have defined WeatherData class which implements Subject Interface which have three methods called registerObserver(), removeObserver(), and notifyObservers() which WeatherData class has to implement in order to register, remove, and notify observers.

Similarly, we have defined Observer and DisplayElement interfaces. Various display classes will implement Observer interface and DisplayElement interface in order to become an observer and display specific information.

Each observer will register it with the subject specified. Once registered, it can get the updates from the subject when there is change in the subject’s state. What if an observer does not want to get update anymore. Well, it can simply unregister itself. Yes, it’s that simple.

The subject on the other hand will have the collection of all registered observers and notify and update each registered observer when there is change in its state.

Have you noticed that the subject does not have any information about observer other than it implements Observer pattern. It enables the subject to register, remove, and notify any kind of observer which implements Observer interface irrespective of their internal implementation. In other words, we can say that both components Subject and Observer components are loosely coupled which leads to our next design principle:

Design Principle

Strive for loosely coupled designs between objects that interact.

The Observer Pattern — defines a one-to-many relationship between objects so that one object changes state, all of its dependents are notified and updated automatically.