Event Handling using Observer Design Pattern

Event Handling using Observer Design Pattern

Another classical application of Observer is Event Handling within programming languages.

Before we can understand how and why observer is preferred for designing event handling, we first needs to briefly understand the chain of responsibility design pattern which is mostly competing with the observer design pattern.

Lets say I am in classroom and I have a problem and I know one of the students in the class might have the answer to the same. So what are the two ways in which I can get my question answered.

  1. I can broadcast the question.. whoever knows the question will answer to the same and I might get the answer. This is the observer way of doing things.
  2. I can pass the question to the first student in the class presuming that they are chained. If the first student knows the answer to the question, he can answer the same else he will pass the request to the next student so the request propagates till either some student has an answer to it or the question gets unanswered . This is the chain of responsibility way of doing things.

Now think about as to when will we prefer either of the two options.

I hope we will agree option 1 will give me the best response time but the number of message packets sent is directly proportional to the number of observer. If the number of Obserevers are large and if the size of the message object is large as well, there are chances that the network bandwidth might get hogged.

In Option 2 if the first student in the chain knows the answer, then just by sending a single message packet and within the quickest possible time while if the last student in the class has the answer then the response time will increase exponentially with equal number of messages.

So in general if response time is important Observer is preferred while if network bandwidth congestion is important .. Chain of responsibility is preferred.

Coming to Event handling event handling can be designed using both Chain of responsibility as well as observer.

Event handling using Chain of Responsibility

Java 1.0 had event handling being implemented using chain of responsibility but was latter implemented using Observer.

The figure shows a typical user interface with a button within a panel and the panel enclosed within a window.

If COR was used to implement event handling, first the button is given a chance to handle the event, if the button can handle the same its OK otherwise the enclosing panel is given a chance to handle the event . If the panel cannot handle the same then the enclosing window is given a chance to handle the event.. This is how different UI artifacts are given a chance to handle the event .. else the event gets unhandled.

The basic problem with COR being used for event handling is the response time. If the last UI element had the event handling logic , then a good amount of time would have got lost before the event was handled. As performance is of great importance in a user interface event handling using COR is not the best possible option.

Event handling using Observer

If Observer is used to handle events, Event Listeners are the Observers while the Event Sources are the Subjects. One or more event listeners subscribe to a particular event source whenever the event occurs the event listeners are notified about the same and one of them then handles the event. Since Observer gives better response time it is usually preffered for event handling moreover the size of the Event object is small and the number of listeners are small as well.

Hence overall Observer seems to be better choice over COR when it comes to event handling.

Hemant Jha
Founder - VPlanSolutions
Researcher, Trainer