As I promised myself every month one design pattern from the book will be described by me on this blog. This month’s design pattern is the observer pattern. I will start with definition this time:
The Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically.
Head First. Design Patterns.
Book examples
There are lots of examples in the book comparing to previous chapter. The observer pattern is compared to newspaper subscription where a newspaper publisher delivers you every edition of the newspaper. You can also unsubscribe and therefore you will not get the newspaper again (unless you start subscribing it again). After this real-life example there is a funny story described. It is called “A day in the life of the Observer pattern”. It also explains with some text and images the way Observer pattern works. But it is still not the end of examples. After the mentioned story we are presented with a comic telling a story of a head hunter and two developers.
All those examples have something in common: there is a subject (the newspaper publisher, the head hunter) and observers (newspaper readers, developers). The observers can get onto “subscribers list” of the subject and then the subjects can inform the observers about changes. The observers can also ask for deletion from the “subscribers list” and therefore they will not get information from subjects anymore. Diagram below presents the observer pattern and basing on it authors of the book lead the reader, step by step, to implementing his own observer pattern.
This own implementation is connected to the main example and issue described in the book: the weather monitoring application. The application should be build for our business partner and should display: current state of weather, forecast and statistic data. We get WheaterData class from our partner which has three interesting for us getters: getTemperature()
, getHumidity()
and getPressure()
. There is also an empty method measurementsChanged()
which is sign for us that we should focus on it and expand it. Of course the answer how to develop it is simple: use the observer pattern. We end up with the code you can download from here and run it in your terminal (I have re-written it from Java to PHP).
After that a new requirement appears and we are presented with more flexible in terms of passing measurements solution. The solution is build-in in Java SDK classes: java.utils.Observable
and java.utils.Observer
. However, authors explain us it is not flexible enough since we can not customize it. They present us also other build-in in Java examples of usage of the observer pattern such as listeners in Swing library. If it goes about PHP since version 5.1 we can use SplSubject and SplObserver interfaces.
Other examples
The listeners in Swing library reminded me at once event listeners in JavaScript. So, this is the example when we didn’t implement the observer pattern but we use it Also, most of today’s web applications use libraries such as jQuery and it has the trigger()
method which we can use instead of implementing the observer pattern. Many examples on the Internet shows using the observer pattern to push AJAX requests via it (i.e. pushing tweets).
It seems the observer pattern in PHP is being used for different logging mechanisms. There are different user or authorization classes implementing Subject/Observable interfaces and once its statuses change all the loggers (which implement Observer interface) are being notified. An interesting example from one of first ten results in Google Search is upload manager which implements Subject interface and notifies a model which puts data into a database table and a logger which puts log data into a log file.
Other design patterns
Here is the list of described by me design patterns: