Design patterns: Observer pattern

What is common between a washing machine that has just completed washing and your secretary who tells you that she is done creating the annual reports? They are both using the observer pattern.

The observer pattern in real life

Using a washing machine plays out the following story. The user tells the machine to do the laundry. The machine performs the long, chugging task. When done, the machine tells you with a buzz. This is true of other appliances like the microwave oven or a toaster. Your smartphone does the same thing…. only it notifies you too much!

Not only appliances. Delegation of work to people works the same way. Efficient delegates will come back to you after they have done your work for you. Without them coming back, you would never know when the work is done.

Let’s imagine what would happen if your washing machine didn’t ping or if your delegate didn’t call you up to say that she’s done.
Without communication, you’d never know if the work is done or when it will be done. So you have two ways to know about the status of work.

One way is to be there while the work is being done and observe it all the time. No need to tell you how much a waste of time this is. Might as well do the work yourself. This is what happens when you fill your water bottle from an electronic water dispenser. The dispenser takes ages to start. Then the dispenser has such a thin spout that it takes at least 90 whole seconds before a 1-litre water bottle is full. If you have a 2-litre bottle, then God help you. The problem is that 90 to 180 seconds is too long to wait for water to fill, but too short to start any meaningful work. The other problem is that you have to turn off the water flow yourself when the bottle is full. If you don’t, then the bottle will overflow and water will be wasted. Not a good use of resources or your time.


Alternatively, you have to initiate the communication. That means interrupting whatever you are doing to frequently check up on the task’s status. This keeps wasting your time and resources. And you cannot focus on whatever is actually important to you. This happens when pasteurising milk on a gas stove. If you overheat the milk, it will overflow from its vessel and spill over. Hence the need to constantly check. But since it takes nearly 10 minutes for milk to boil, you can work on your important task for at least the first five minutes.

I have seen devices which solve both the problems effectively. I have seen water dispensers which have a dedicated 1-litre button, that dispenses exactly a litre of water and pings when done. You just keep your empty bottle under the dispenser’s spout and go back to your work. Likewise, I have an electric stove that slowly boils milk for 20 minutes at a certain temperature and then turns itself off with a beep. The milk is perfectly boiled at the end and there’s no spillage.

So, what’s the observer pattern?

Let’s use a domestic bread toaster as an example as we describe the observer pattern. Your spouse and you want to eat toast for breakfast. Your spouse puts slices of bread into the slot on the toaster while you switch on the button that starts the toasting process. Your spouse and you are the delegators. The toaster is the observee or delegate. The process of toasting has been delegated to the toaster.

Next, someone wants to know when the toaster is done. This is the Observer. One one hand, you yourself can be the observer, responding to the toaster’s ping. Otherwise you can tell another person, say your parents or children, to attend to the toaster’s ping. This person is the observer. Thus, the delegator may not always be the observer.

Click on the image to open an enlarged version.
Click on the image to open an enlarged version.

The Observee and Observer have a set of events which are agreed upon. This agreement is represented by an interface in object-oriented programming. See this post to learn what interfaces are. In our case, the observer wants to know when the toast is done. Let’s call this the onToastDone method. By terms of the agreement, the Observee (toaster) promises to call the onToastDone method on the observer (toaster sounds a ping) as soon as the toast is done. The Observer promises to receive the call and act upon it (removing the finished toast from the toaster).

Observer pattern in software

It is common knowledge that the speed at which data is read from a hard disk or from the Internet are much slower than the speed of a computer’s processor itself.  The observer pattern is used to good effect here.

In almost any modern programming language, you will notice that calls to load files from the hard disk and Internet are based on the observer pattern. Your program will request the hard disk to load a file, but then move on to do the next thing. Internet requests are handled similarly. The hard disk or the network operation will later let the app know that the requested resource is loaded and ready for use. What would happen if the app were to wait for the hard disk or Internet to finish its job before moving on? You would have an ugly, irresponsive app that fails to respond to your clicks and taps. Happily, the observer pattern keeps your app responsive.


Delegation and observation help us focus on tasks that are important to us. They help us move on from time-consuming tasks and start the next one, keeping our day active. Please let me know interesting examples of observer pattern that you have witnessed.