Delegates vs. Observer Patterns

Question

Are there any recommendations for using a delegate for indirect association and observer?

In C #, you can use delegates for simple callbacks. I think function pointers and member function pointers can be considered delegates (am I right?).

I understand that to use an observer, you need to create an interface and implement it, therefore it is more strongly typed and relations are more formal. For a delegate, as long as the function signature and accessibility match, you can “plug them in”.

Do delegates make the observer pattern controversial? How do you define a delegate versus an observer pattern?

Answer 1

The observer pattern is already implemented for you in the form of events .

The advantage of events is that they can have multiple subscribers, while with a delegate you can only have one. This makes events much better for public interfaces and scripts in which you do not have full control over who wants to be notified that something is happening. In fact, events are simply managed delegate lists. You will need to understand what makes sense in your scenario.

Edit: As the commentator rabbi notes , the above is not entirely true, since any delegate can become a multicast delegate. The purpose of the event modifier is to make a delegate that can only be called inside the class that defines it. This is most useful for providing encapsulation in public interfaces.

Answer 2

One of the advantages of the observer template is that if you have a large number of events that are usually signed by the interested party, then transferring one object to the event subscription method is much easier than subscribing to each event individually. With the lack of C # specifications of interfaces and methods for anonymous classes, how can this be done with Java , the implementation of the observer pattern becomes a little more time-consuming, so most options for using events in any case.

Another advantage of the traditional observer pattern is that it copes better when you need to interrogate a subscriber for some reason. I came across this need with objects that cross the border of a web service where there are problems with delegates, while the observer pattern is just a link to another object, so it works fine as long as your serialization maintains the integrity of the links inside the object like the NetDataContractSerializer. In these cases, it is possible to distinguish subscribers who must be deleted before making the service boundary, based on whether the reference subscriber is included in the same object graph.

Answer 3

Delegates can be used to implement an observer pattern - think about events.

To do this without events, look here: http://www.dofactory.com/Patterns/PatternObserver.aspx

It didn't take much to refactor to use delegates if you prefer.

The only advantage I can come up with when implementing the interface is the consistency of the member name in all implementations.