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?


+5  A: 

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).

Reed Copsey
I really love the C# event system. The one downside to it, IMHO, is that because you don't explicitly have attach/detach api method calls visible to the user, a lot of people don't know to detach/remove the event handler when they are done with an object. Thus keeping the object away from the garbage collector.
@Matt, yes indeed! Those are so much fun to debug when your app runs out of memory.
Cylon Cat
+3  A: 

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:

and i used his post to create my event aggregator which i put into a messaging-based architecture for my winforms / handheld apps:

Derick Bailey

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.

Jerod Houghtelling
Why is unit testing easier with the classic method?
@Matt I don't have a definite answer on that, but Mocking may be easier.
Jerod Houghtelling
all of the current mocking systems (rhino mocks, moq, etc) support events with ease. if you are writing your own mocks, manually (i'm sorry...) then yes, a classic observer would be easier to mock because it's just an interface and not a delegate. but you aren't rolling your own mocks, right? ... RIGHT? :)
Derick Bailey
@Derick correct I'm not rolling my own mocks. I use both Moq and Rhino. After reading your answer to this orginal question, I almost deleted my answer. Yours is very well done while mine is vague and unspecific.
Jerod Houghtelling
+3  A: 

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.

oh nice! i'm not on .net 4 yet, so i wasn't aware of those. but that's exactly what i would use for my event aggregator if i rewrite it in .net 4
Derick Bailey
In particular, Reactive Extensions (a MS research project) makes good use of this more powerful observer framework to express some very powerful things:
Dan Bryant

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.

Tim C
+1  A: 

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.

Cylon Cat

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.