Observer Pattern
We have one object whose state keeps changing and there is another object which wants to know whenever the state has been changed. Think of something like an RSS client which wants to know when a new article has been published or a broadcast message which delivers to all the recipients.
Push Vs Poll
Observer pattern is essentially about moving to a push architecture from a poll architecture. Poll architecture is calling an object indefinitely to know if it has changed it state. If you go with this architecture the update frequency will be a concern as you do not know how often the object will change its state. This approach would be very absurd when there are many objects which wants to get updated based on the change. The point here is we are asking for the data without even knowing if the object really has new data.
Now we know asking is a bad idea. Push architecture is essentially letting know the subscribers that I have changed. It’s essentially pushing the notifications whenever there is a change. Observer pattern does the same thing. But the key here is all the observers which are interested in the updates need to be registered with the observable so that they will be notified about the change.
Observer pattern defines a one to many dependencies between objects so that one object changes the state all its dependencies are notified and updated automatically.
UML Diagram
IObservable is the thing that undergoes changes and can be observed. IObserver is the one interested in those changes and it can observe. There is a one to many relationships between them indicating that IObservable has zero or many observers interested in the change, so IObservable has many IObservers. IObservable wants to keep track of things which are interested in changes, so it has methods to add, remove an observer and to notify about the change. Coming to IObserver we have an update method to update when the change from IObservable is received. IObservable notifies the IObserver by calling method update. ConcreteObservers will be responsible for their implementation when update is called on them.
Now coming to the concrete classes of ConcreteObservable and ConcereeObserver implementing IObservable and IObserver. These concrete classes provide the implementations for these interfaces. Concrete Observer has a reference to Concrete Observable which is done to know what has changed and to read information from the concrete observable when update method is called.
Example
Let’s say we have a Weather Station (sensor) which gives the temperature information and updates it frequently. Whenever temperature changes it notifies all the observers of the changes. These observers can be any displays such as Phone Display and an LCD display.
Weather Station is an IObservable, Similarly Phone and LCD displays are concrete observers implementing IObserver. We also have a GetTemperature method in weather station which allows the observers to get the current temperature.
Code
Below is the implementation for the example we have discussed. The heart of the observer pattern lies in the notify method of weather station where we call update method on each observer registered with the observable informing regarding the change. Since the observers have reference to the observable, they call the method to inspect the current data of the observable.
GitHub: Observer Pattern
#13DayOf100DaysOfCode
Comments