Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Follow the Chain of Responsibility

Run through server-side and client-side CoR implementations

  • Print
  • Feedback

Page 4 of 4

Using the CoR pattern for event handling was doomed to failure because event handling requires subclassing components. Because an average graphical user interface (GUI) uses many components, and most components are interested in at least one event (and some are interested in many events), AWT developers had to implement numerous component subclasses. Generally, requiring inheritance to implement a heavily used feature is poor design, because it results in an explosion of subclasses.

The original AWT event model was eventually replaced with the Observer pattern, known as the delegation model, which eliminated the CoR pattern. Here's how it works:

import java.awt.*;
import java.awt.event.*;
public class MouseSensor extends Frame {
   public static void main(String[] args) {
      MouseSensor ms = new MouseSensor();
      ms.setBounds(10,10,200,200);
      ms.show();
   }
   public MouseSensor() {
      Canvas canvas = new Canvas();
      canvas.addMouseListener(new MouseAdapter() {
         public void mousePressed(MouseEvent e) {
            System.out.println("mouse down");
         }
         public void mouseReleased(MouseEvent e) {
            System.out.println("mouse up");
         }
      });
      setLayout(new BorderLayout());
      add(canvas, "Center");
   }
}


The delegation model—where a component delegates event handling to another object—doesn't require extending component classes, which is a much simpler solution. With the delegation event model, event methods return void because events are no longer automatically propagated to a component's container.

The CoR pattern was not applicable for AWT events because GUI events are much too fine-grained; because there are so many events, and components handle them so frequently, the CoR pattern resulted in an explosion of subclasses—an average GUI could easily have upwards of 50 component subclasses for the single purpose of handling events. Finally, propagation of events was rarely used; typically, events are handled by the component in which they originated.

On the other hand, the CoR pattern is a perfect fit for servlet filters. Compared to GUI events, HTTP requests occur infrequently, so the CoR pattern can better handle them. And event propagation is very useful for filters because you can combine them—much like the Unix pipes discussed at the beginning of this article—to produce a myriad of effects.

Last link

The Chain of Responsibility pattern lets you decouple an event's sender from its receiver with a chain of objects that are candidates to handle the event. With the classic CoR pattern, one or none of the objects in the chain handles the event; if an object doesn't handle the event, it forwards it to the next object in the chain. In this article, we examined two CoR pattern implementations: the original AWT event model and servlet filters.

About the author

David Geary is the author of Core JSTL Mastering the JSP Standard Tag Library (Prentice Hall, 2002; ISBN: 0131001531), Advanced JavaServer Pages (Prentice Hall, 2001; ISBN: 0130307041), and the Graphic Java series (Prentice Hall). David has been developing object-oriented software with numerous object-oriented languages for almost 20 years. Since reading the GOF Design Patterns book in 1994, David has been an active proponent of design patterns, and has used and implemented design patterns in Smalltalk, C++, and Java. In 1997, David began working full-time as an author and occasional speaker and consultant. David is a member of the expert groups defining the JSP Standard Tag Library and JavaServer Faces, and is a contributor to the Apache Struts JSP framework. David is currently working on Core JavaServer Faces, which will be published in the spring of 2004.

Read more about Core Java in JavaWorld's Core Java section.

  • Print
  • Feedback

Resources