JafTalks

Do you want a component to be notified with the changes of another component? Do you want to define one-to-many dependency between objects and make the update automatic?

The separation of concerns is the developers’ phobia as well as their passion. Software developers always try to keep the codes in the View layer minimal, and make the separation between business and presentation their first priority.

To see it clearly, let's suppose that the market of an X organization introduces new business edges and the production team has to create a new mobile website for their existing product, do they have to re-implement the application from scratch? Of course not, just they have to implement the mobile presentation layer only. Now let’s suppose that the two applications are running and the administrator changed the data on the server and wants to notify both the mobile and web application users with the updates! How to implement this scenario? Two times? Duplicate work? Of course not.

The observer design pattern is a good solution to solve this design problem; we’ll define an object that will be the publisher of the data model and delegated all the views functionality to decoupled and distinct observer objects. Observers register themselves with the Subject as they are created. Whenever the Subject changes, it broadcasts to all registered Observers that it has changed, and each Observer queries the Subject for that subset of the Subject’s state that it is responsible for monitoring.

To implement the observer design pattern you can use normal .NET events, so the observers will subscribe to the events of the Publisher and in consequence they will be notified in any changes on the Subject.

But what if a non-.Net object wants to know of the changes of the Subject too? How shall they be notified?

Ladies and Gentlemen please welcome .Net 4.0 with its newly introduced interfaces IObserver<T> and IObservable<T>, which will help in building loosely coupling system between the data provider and the observers. Whilst IObservable<T> provides all the functionality for the publisher, IObserver<T> does the same for subscriber. You will find that publisher and subscriber are also known as provider and observer. Whatever name is used for, keep in mind what each item is supposed to do, otherwise you will feel confused.

Notice that both interfaces are generics by <T>. Actually, IObservable is covariant with <T> whereas IObserver is contravariant with <T>. The reason is that whilst IObservable could provide push-based notification methods to the indicated type <T> and more derived <T> types, the IObserver only could observe such derived types from <T’> to <T> where <T’> is the derived type of <T>, i.e. IObserver could use <T> and less derived types. The contracts of both interfaces are declared as follows:

public interface IObserver<in T>

{
     void OnCompleted();
     void OnError(Exception error);
     void OnNext(T value);
}
public interface IObservable<out T>
{
    IDisposable Subscribe(IObserver<T> observer);
}

I wish to be observed

That said, the main target of an observable object is to be observed by a bunch of observers. Observable owns just one method used for subscribing in an observer. On the other hand, each time an observable object push a new notification it would be caught by OnNext observer’s method. Let’s see an example.

Now, I wish to observe

Let's run the application and see how the observers are subscribed to the temperature change in the weather and how they're been notified.

Let's see the output screen:

To download the source code click here.