Observer design pattern and C# event delegate model

Question

It seems that the observer design pattern is in built in C# through its event delegate model. Is there any reason where I may have to implement it in the classical way?

regards
123Developer

Answer 1

Typically, the event model built into the language will be sufficient for the observer pattern. There is really no reason to implement it in a different way, since you're just recreating events.

That being said, there are rare times when people change the "standard" event pattern. For example, I have seen cases where people want to raise events asynchronously. I typically don't recommend this (I, personally, think this is better handled on the subscriber's side), but it still can be handled via a standard C# event, but raising the event changes slightly (using GetInvocationList and asynchronously calling the delegates).

Answer 2

you're correct. the observer pattern is implemented in the C# event system, using delegates.

the #1 reason you would want something closer to a classic observer is even aggregation to facilitate domain events and/or composite application architectures.

jeremy miller has a great post on event aggregator: http://codebetter.com/blogs/jeremy.miller/archive/2009/07/21/braindump-on-the-event-aggregator-pattern.aspx

and i used his post to create my event aggregator which i put into a messaging-based architecture for my winforms / handheld apps: http://www.lostechies.com/blogs/derickbailey/archive/2009/12/22/understanding-the-application-controller-through-object-messaging-patterns.aspx

Answer 3

I agree that the classic observer design pattern is simplified greatly in C#. I think there are probably cases out there that are 'safer' to use the classic implementation. The things that come to mind are multi-threading and public APIs. I would think unit testing may sometimes be easier if you do the classic way. But, like you've mentioned there is a much easier shortcut now with C# delegates. Sorry, I don't have a definitive answer of when you would have to use the classic pattern.

Answer 4

I think generally there is no real reason why we should not use C# delegate model to implement the Observer pattern. But, in .Net 4, they added IObserver<T> and IObservable<T> interfaces to implement push based notification system. So, I guess that is one of the cases where you would want to use the interfaces rather than the event based model.

Answer 5

I would take a look at this post:

Similar Question on SO

I particularly like one comment from Jon Skeet:

Absolutely. This is a bit like asking, "Should I implement the iterator pattern or use foreach and IEnumerable?"

Which was in response to this well said answer:

Hmm, events can be used to implement the Observer pattern. In fact, using events can be regarded as another implementation of the observer-pattern imho.

But the selected answer is quite good and applicable.

Answer 6

I agree that .NET's event handlers take care of most of your needs for the observer pattern. However, there are a couple of interfaces that you'll want to be aware of, especially for Silverlight and WPF. These are INotifyPropertyChanged and INotifyCollectionChanged. These prescribe specific patterns that Silverlight and WPF expect for databinding. Also, there's an ObservableCollection class that implements INotifyCollectionChanged; this saves a lot of hassle when building Silverlight and WPF interfaces.

Answer 7

Ladies and Gentlemen please welcome .Net 4.0 with its newly introduced interfaces IObserver and IObservable, which will help in building loosely coupling system between the data provider and the observers. Whilst IObservable provides all the functionality for the publisher, IObserver 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.

http://www.jaftalks.com/Home/Show/Observer-Design-Pattern-DotNet4