What are the advantages of the delegate pattern over the observer pattern?

Question

In the delegate pattern, only one object can directly listen to another object's events. In the observer pattern, any number of objects can listen to a particular object's events. When designing a class that needs to notify other object(s) of events, why would you ever use the delegate pattern over the observer pattern? I see the observer pattern as more flexible. You may only have one observer now, but a future design may require multiple observers.

Answer 1

You're looking at things incorrectly. An observer sees that a particular event occurs. It does not impact it, or own it. A delegate handles a particular event, and has ownership of the handler, even if the delegator owns the interface to the event.

Answer 2

There is no delegate pattern per se. I am going to assume you mean Delegation Pattern.

As I understand it, they're the complete reverse of each other and used for different purposes.

Generally, with an Observer Pattern, any number of observer objects will listen to an event on a second object and act on the event. The second object has no knowledge of its listeners. It just calls out to them.

A delegate object is passed to the second object which calls methods directly on the delegate. And therein lies the advantage you're looking for. Rather than sending a single message to multiple listeners, it has complete control over a single object (at a given time). See also Inversion of Control.

Answer 3

The delegate pattern, as I understand you, is know as the event handler mechanism in other languages, for example Delphi. As such it simply is an implementation of the observer pattern with a major restriction: only one listener at a time.

The disadvantage of event handlers or delegates is obvious: only one observer.

The advantage is not so obvious: performance. With an observer pattern you can add many observers. When an event occurs that the observers need to be notified about, you will need to enumerate the observers and send a notification to each. This can quickly bog down any observed instance, especially when the number of events that require notification is significant as well.

Answer 4

That's a question of several trade-offs.

Trade-offs:

• flexibility (in terms of having n > 1 delegates/observers)
• cost of sending a message
• resilience (ability to sustain unavailability of delegate/observers)
• ease of use

Delegate pattern:

• not very flexible - adding more than 1 delegate is not possible (implies some form of "multi-delegate" i.e. observer pattern)
• sending a message is cheap, O(1) - same cost as calling any other function or method (no look-up, message queue or other infrastructure required)
• usually not resilient - delegates are expected to be present and do their part of the work, i.e. the sender tends to fail if not delegate is known
• easy to grasp, easy to implement

Observer pattern:

• very flexible - adding n > 1 observers is expected by design
• sending a message has a cost implied by number of observers, O(n), i.e. n observers take n time and messages (at least in a naive implementation)
• usually resilient - observers are not generally expected to do any work on part of the sender. That is even if there is no observer the sender is unaffected
• can become rather complex to grasp, in particular of observers are expected to react to messages (does the order matter?, which observer responds in which way?)