Question

After reading the Head First Design Patterns book and using a number of other design patterns, I'm trying to understand the Observer pattern. Isn't this already implemented using Events in the .NET Framework?

Was it helpful?

Solution

Yes, it is. The observer pattern is also called the publish/subscribe pattern, which is exactly what events allow you to do.

OTHER TIPS

I would say yes, it was Anders Heljsberg's intent to make the observer pattern a first-class language feature with events in C#, based on his experience with Delphi. Anders makes this and other design intentions clear in an excellent interview on Software Engineering Radio.

Yes, it's identical.

A note: if you really want to understand events, I recommend learning the observer pattern and implementing it yourself a for a while. Once you fully understand it, stop doing it yourself and use the professional and well-documented implementation unless you have a real need to do otherwise.

That's right, events are an implementation of the observer pattern. I have read discussions , though, of people who still write their own, to give them either more flexibility, or maybe just to avoid the event-raising syntax.

Yes, but programming the observer pattern explicitly and thus not using delegates and events can result in easier debugging of your code.

Consider the difference:

public void NotifyObservers()
{
    foreach(Product product in ProductList)
    {
        if (product is IProductObserver)
        {
               product.Update(this)
        }
    }
}

Here it is very clear what products in the list get notified of a change. While debugging you can inspect the ProductList...

With using delegates and events it can be more cumbersome to find out how many "delegates" were actually "subscribed" to handle the event.

Most modern languages have native support for some of the design patterns. It has been argued that languages are better the more patterns they support natively without the need to implement them explicitly, and that Lisp is excellent in this regard. Jeff had something to say about that, too.

Microsoft Itself States that using events and delegates is the c# way of applying the Observer Pattern. Using some basic naming conventions for events and delegates they named their own pattern as "Event Pattern" which does exactly the same thing providing some extra advantages over the classic Observer Pattern.

"Event Pattern" is described in the MSDN Library inside the "Exploring the Observer Design Pattern" Article.

Reference MSDN Article

Based on events and delegates, the FCL uses the Observer pattern quite extensively. The designers of the FCL fully realized the inherent power of this pattern, applying it to both user interface and non-UI specific features throughout the Framework. This use, however, is a slight variation on the base Observer pattern, which the Framework team has termed the Event Pattern. In general, this pattern is expressed as formal naming conventions for delegates, events, and related methods involved in the event notification process. Microsoft recommends that all applications and frameworks that utilize events and delegates adopt this pattern, although there is no enforcement in the CLR or standard compiler

Based on this examination of the Observer pattern, it should be evident that this pattern provides an ideal mechanism to ensure crisp boundaries between objects in an application, regardless of their function (UI or otherwise). Although fairly simple to implement via callbacks (using the IObserver and IObservable interfaces), the CLR concepts of delegates and events handle the majority of the "heavy lifting," as well as decreasing the level of coupling between subject and observer.

No, they achieve the same intent, however they are different. I would say that the Observer pattern is quite a hack of over design to achieve something you could have achieved easily with functional programming, and that .NET events uses functional programming to achieve the same goal.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top