CODEWITHSUNDEEP
c#design-patterns
123Developer
123Developer

Reputation: 1493

Observer design pattern and C# event delegate model

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

Upvotes: 5

Views: 2627

Answers (6)

Cylon Cat
Cylon Cat

Reputation: 7201

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.

Upvotes: 1

Tim C
Tim C

Reputation: 1934

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.

Upvotes: 0

decyclone
decyclone

Reputation: 30840

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.

Upvotes: 2

Jerod Houghtelling
Jerod Houghtelling

Reputation: 4867

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.

Upvotes: 0

Derick Bailey
Derick Bailey

Reputation: 72868

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

Upvotes: 3

Reed Copsey
Reed Copsey

Reputation: 564461

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

Upvotes: 6

Related Questions