Design Patterns #2: Observer

Dzień dobry!
Continuing on design patterns – it’s time for the Observer. This pattern allows linkage between one observable and many observers that when the observable changes its states the observers are automatically notified and updated. So, the observable has a collection of observers, it performs its actions and when certain defined event happens it notifies its own observers. Let’s take a look at the diagram:

Let’s start with the observers: their interface defines only one method: Update(). That method returns void and can take parameters. In fact parameters are used to notify the actual change and not only the fact that the value has changed. It will be later shown in the example.
Now the observable: it must have possibility to add and remove observers (Register() and Unregister() methods respectively, as an argument they take  object that implements IObserver interface) and to notify its observers about the change. Concrete implementation of the observable also has some sort of observers collection. (This collection is not part of the interface because a) it doesn’t have to be public, b) methods to register and unregister the observers are exposed publicly and that’s enough for the client, it doesn’t have to know how references to the observers are stored. Of course it doesn’t have to be like that. What we’re discussing here is just the pattern and its actual implementation may vary depending on every particular need.) Usual implementation of Notify() is iteration through the observers collection and invoking Update() method on each of them. And that’s it. Let’s go with the example.

Example given in the book (previous post explains what book) is a weather station (measures temperature, pressure etc.)  and several types of display (current conditions, stats etc.) I think that’s a really good example but our example will be simpler but similar to some extent. We’re going to build number generator and two types of display.

Have a quick look at the code below:

Hey, where’s Notify() method?! We don’t want that method to be exposed publicly therefore it won’t be here in the interface. As said earlier, the design patterns are not exact implementation nor have strict code structure, they are more of a general ways to achieve some result. But if you hear from another developer that he has used the observer pattern (or any other pattern) you will instantaneously know what to expect.
IObserver interface defines only one method which is Update() that takes one integer parameter which will be passed to our observers.

Concretions – Number Generator

Our number generator will – surprise, surprise – generate random numbers within given range (which is specified by constructor’s parameters). It has list of objects of type IObserver and two methods that allow adding and removing from that list. Method notify() is private as we don’t want to make it possible from the outside of the class to force the observable to notify its observers. This method (as you can read above in this post) simply iterates through observers collection and invoke Update() method on each of them. This method is invoked inside Next() method which generates next random number. Parameter of the Update() method is last generated number.

Concretions – Observers

These two implementations of IObserver using their Display() method print their current readings to console. One of them displays aggregated value of all random number passed from the observable, and the other displays average value. Their Update() are consistent with the interface they implement.

Wiring all together
All the above classes will work together in this small console app.

As you can see once we have an instance of NumberGenerator we can register some observers. Our console app will iterate 10 times and draw 10 random numbers and display readings of our observers.

The example above shows basic implementation of the observer pattern. It may be improved by allowing object to self-register/unregister. This can be simply done by storing reference to observable in the observer. In this case observer will need appropriate methods: to register that takes observable as an argument, and to unregister with no arguments. Let’s take a look at its interface:

It extends existing IObserver interface and adds two methods as described earlier. Now, the concretion:

So, it now has a reference to the observer which initially is null. When we want to self-register it to a particular observer we simply invoke SelfRegister() method and pass the observer as an argument. The method will save the reference to the observer and invoke observer’s Register() method with this passed as an argument. SelfUnregister() method performs opposite actions. The code says it all 🙂
Below you will find to txt file with the source code. Thanks for today, and hopefully see you next week. Cheers!

Source code: download txt file