The major problem was that an event could only be handled by the component that originated the event or by one of the containers that contained the originating component. This restriction violated one of the fundamental principles of object-oriented programming: Functionality should reside in the most appropriate class. Often the most appropriate class for handling an event is not a member of the originating component's containment hierarchy.
Another drawback of the original model was that a large number of CPU cycles were wasted on uninteresting events. Any event in which a program had no interest would ripple all the way through the containment hierarchy before eventually being discarded. The original event model provided no way to disable processing of irrelevant events.
In the new delegation event model, a component may be told which object or objects should be notified when the component generates a particular kind of event. If a component is not interested in an event type, then events of that type will not be propagated.
The delegation model is based on four concepts:
One subclass of EventObject is java.awt.AWTEvent, which is the superclass of all the delegation model event classes. Again, there is only one method of interest:
An event's ID is an int that specifies the exact nature of the event. For example, an instance of the MouseEvent class can represent one of seven occurences: a click, a drag, an entrance, an exit, a move, a press, or a release. Each of these possibilities is represented by an int: MouseEvent.MOUSE_CLICKED, MouseEvent.MOUSE_DRAGGED, and so on.
The subclasses of java.awt.AWTEvent represent the various event types tyat can be generated by the various AWT components. These event types are
There are two ways to handle the events listed above. The first way is to delegate event handling to a listener object. The second way is to explicitly enable the originating component to handle its own events.