Read this article in your language IT | EN | DE | ES

The observer pattern has played a key role in all aspects of Object Oriented Development. The key purpose of this pattern is to allow a Model to focus completely on State Management without being forced to deal with details involved with the usage of the Model’s Data.

This offers Code Isolation to the lowly Model (Business Object) Developer, and well as promotes an endlessly rich landscape of ‘Views’ which may bind to the State of the Model to do what they please.

Recently, as Service Oriented Architectural Patterns have graduated into Duplex-Style client interaction, Views for many Business Layers are slowly becoming more unpredictable at the time of crafting a solution.

For instance, it is common in an Enterprise Environment for a Business Layer to Manage a Global State while Rich Internet, WinForm, Mac, Mobile, and Terminal Clients all interact with the Model seamlessly across Platform Agnostic Service Tiers.

With this in mind, the Observer Pattern can be used initially to as a layer of Abstraction and Control between the Model and its View.

Goals to creating Models Independent of Views:

• Model has the ability to Update View on demand
• Model has no knowledge of how data is being used in a View
• No View has any knowledge of other Composite Views Observing the same Model

The Details of the Pattern

Define an IObservable and IObserver interface:

Above, the IObservable Interface defines the scaffolding for an Observable Model. A Model will be able to accept Entry/Exit from a View implementing IObserver.

There are three important features made available by defining these interfaces:

1. The IObservable Interface defines a specification for Registering and Unregistering Observers. Since the Observers are Abstracted behind a IObserver Interface, the IObserverable Concrete Implementation is independent of the number of Observering Instances.
2. The IObservable Concrete implementation maintains the Observers instances within its own State. This allows the Model to activate “NotifyObservers” whereby the current state of the model can be passed down to each individual view to trigger DataBinding
3. The View does not communicate to the Model, and thus has no knowledge, nor control, of any other view.

Under the hood, what the interfaces do not show, is that the typical implementation of the NotifyObservers Method on the IObservable Instance will iterate through all of its IObserver Views calling Update, passing calling Model’s State as the parameter.

Observer Pattern Geospatial Example

A example of this pattern can be seen geospatially with a Movie Theater scenario where many patrons have the ability to claim that they can See, or not See, the screen given the position of the curtain:

Given that the instance of TheatreScreen is a real movie theatre, the Left Curtain is either Open or Closed. If two patrons are created sitting on the farthest sides of the theatre, each one will be effected independently based on the curtains position.

The Observation of the being able to see from the perspective of a single patron is mutually exclusive of Observations of other viewers.

When the Curtain State Changes, the Model is in charge of informing, in this case visually, that they need to reevaluate their ability to clearly see the screen. The Model does this through NotifyObservers, where each View’s Update method is called with the Models current state passed as the paramter.

Each patron, on the receiving end, will simply wait for Update to be called with the most recent Model State.