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.
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.
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.
5
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?)
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.
4
This is an old post but I’m going to chime in anyway because the other answers don’t deal with what’s happening when using either pattern, they seem to be more about theory than practice.
How Delegation and Observer Work
With Delegation the delegator picks exactly who is going to respond to a particular event the moment the source of the potential event is created. You could think of this listener as a single observer. In the case of the Observer pattern the observer picks who it’s observing whenever it feels like it; so the dependancies are reversed when it comes to observer vs delegation.
With the observer pattern think of a newspaper and subscribers as observers. The observers are in control of when the relationship gets created. With delegation think of an employee and an employer. The employer is in control of when the relationship gets created and exactly who is in charge of specific events. Employees can’t pick what tasks they are working on…generally.
Some argue delegation can have one observer but I think the real difference between the two is how event handling is assigned. You will never see a delegate register for an event. It will never know its even handling the event till it happens and the delegator calls a public method on it.
Delegation Advantage
This pattern is very rigid and with most regid designs its simpler and generally more robust. It forces you to declare your event handler up front at the time of initializing the source of the potential event. If you need someone to direct traffic you assign a traffic director before you open up the street. In the case of the observer you would let the traffic cop choose when to direct traffic any time he or she felt like it.
Delegation Disadvantage
The disadvantage of this design is that it’s not flexible. If you were implementing some code for subscribing for a newspaper the newspaper/delegator would have to identify exactly who can read the news stories the second they are created. With the observer pattern they can be registered later at any time and the newspaper will only have to know that a new person has signed up.
When To Choose Delegation?
When you need one specific observer(s) for sure and there is no reason for you to change who is observing then the rigid design of the delegation pattern will be beneficial.
For example, you need a class/object to handle creating a pop-up for a specific error. There aren’t many reasons why at run-time you would need to switch who is handling a specific error so delegating the “Out-of Memory” error to a single entity would make sense. Creating an array of potential handlers and then having those handlers register for the “Out-of Memory” error wouldn’t make much sense; that would be an example of using the observer pattern in this situation. At run-time you might want to change what methods get called or what “delegate” gets called for variable events but swapping out an event handler for a specific event at run-time isn’t normal.
Its not impossible to swap delegates like you would do in the observer pattern, its just complicated. In the real world perhaps you want to swap traffic cops so a new delegator is handling traffic. One could argue that a better design would make original delegate a police station and not a single police officer but I digress…