Head First Design Pattern summarize / chapter 2 ‘Observer Pattern’

Mai Waleed Abu Ajamieh
4 min readFeb 7, 2021

Here we will go through a summarize for the next chapter in the ‘ Head First Pattern ‘. Don’t forget to check this article for chapter 1.

This chapter about one of the most famous design patterns, the Observer Pattern.

We will go through the Weather Monitoring application to discover this new pattern.

In this app, there are three players, the weather station (the physical device that gain the actual weather data), the WeatherData object (follows the data from the Weather Station and updates the displays), and the display that views users the current weather conditions.

Okay, The app task exactly is to use the WeatherData object to update three displays for current conditions(temperature, humidity, and pressure), weather stats, and a forecast.

The three display elements that we need to implement are a current conditions display, a statistics display and a forecast display and These are the displays that must be updated each time WeatherData has any new measurements.

Which means we need to observe the WeatherData measurements.

We can send the new values at measurementsChanged() function in weatherData Class to these three displays.

Let's see The wrong here with our implementation, By coding to concrete implementations we have no way to add or remove other display elements without making changes to the program. so we need to encapsulate the area of changes(temp, humidity, pressure) _ remember chapter 1_. So let's have a common interface to talk to the display elements, they all have an update() method that takes the three changeable values.

Okay, let's meet the observer pattern to see how it will help us.

It's too similar to the way that how newspaper or magazine subscriptions work:

‘A newspaper publisher goes into business and begins publishing newspapers.

You subscribe to a particular publisher, and every time there’s a new edition it gets delivered to you.

As long as you remain a subscriber, you get new newspapers.

You unsubscribe when you don’t want papers anymore, and they stop being delivered.

While the publisher remains in business, people, hotels, airlines and other businesses constantly subscribe and unsubscribe to the newspaper.’

Then according to this direct and simple example, we can say that we have something that we want to observe ‘ observable ‘, the ‘ observer ‘ the object that will be updated according to the received values from the observable.

Also, we need a way to connect the observer with observable ‘ like subscribe ‘.

Return back to the Weather Monitoring application we have the three displays as observers, the weatherData measurements as observable.

And we will create a subject interface that will act as the ‘ subscribe and unsubscribe action ‘ in the app.

Applying this to our app will lead to the below diagram .

So far we’ve built our own code for the Observer Pattern, but Java made our life easier ao already has a built-in Observer interface and the Observable class in java.util package. These are too similar to our Subject and Observer interface, but in advance give you a lot of functionality out. With Java’s built-in support, all you have to do is extend Observable and tell it when to notify the Observers. The API does the rest for you To feel more with java.util.Observer and java.util.Observable, check out this reworked OO design for the WeatherStation:

See you soon in the next chapter.

*all images and diagrams were taken from the book.

--

--