Observer Design Model and C # Event Delegate Model

Question

It seems that the observer design pattern is embedded in C # through its delegate event model. Is there a reason I might have to implement it in a classic way?

considers
123developer

Answer 1

Typically, an event model embedded in the language will be sufficient for the observer pattern. In fact, there is no reason to implement it differently, since you are simply recreating events.

Saying, there are rare times when people change the "standard" pattern of events. For example, I have seen cases where people want to raise events asynchronously. I usually do not recommend this (I personally think that this is handled better on the subscriber side), but it can still be handled using the standard C # event, but the event raise is slightly changed (using GetInvocationList and delegate asynchronous call).

Answer 2

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

the number 1 reason you need something closer to the classic observer is even aggregation to facilitate domain events and / or composite application architectures.

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

and I used my post to create an event aggregator that I introduced into the messaging architecture for my winforms / handheld applications: http://www.lostechies.com/blogs/derickbailey/archive/2009/12/22/understanding- the-application-controller-through-object-messaging-patterns.aspx

Answer 3

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

Answer 4

I agree that .NET event handlers take care of most of your needs for an observer pattern. However, there are a few interfaces you want to know about, especially for Silverlight and WPF. These are INotifyPropertyChanged and INotifyCollectionChanged. They prescribe the specific patterns that Silverlight and WPF expect for data binding. In addition, there is an ObservableCollection class that implements INotifyCollectionChanged; this saves a lot of hassle when building Silverlight and WPF interfaces.

Answer 5

I agree that the classic observer design pattern is greatly simplified in C #. I think there are probably cases that are “safer” to use the classic implementation. What comes to mind is multi-threaded and public APIs. I think unit testing can be easier if you make the classic way. But, as you already mentioned, now with C # delegates is much easier. Sorry, I do not have the final answer when you have to use the classic template.

Answer 6

I would look at this post:

A similar question on SO

I especially like one comment from Jon Skeet:

That's right. This is a bit like the question: "Should I use an iterator pattern or use foreach and IEnumerable?"

What was in response to this well said:

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

But the selected answer is good enough and applicable.