It may have already occurred to you that the event model could get unmanageable rather quickly. For instance, if a given object wanted to listen for events from a large number of event source objects, it would have to implement the interfaces for every one. This may not be the best approach if only a few of the events that are supported by the event listener interfaces are of interest. Another problem occurs when an object is listening for events from two or more objects that are sources of the same event types. Since an object can only implement an event listener interface once, it would have to figure out for itself which object was the source of the event.
Neither of these problems is insurmountable, but each can (and often will) lead to code that is hard to read and even harder to maintain. One way of dealing with this is to introduce another object—an event adapter—between the event source and the event target. The purpose of this object is to adapt the source to the specific needs of the target: thus the name. Figure 3.1 shows a diagram of the object interaction using an adapter.
Figure 3-1. Using an adapter to handle events
Because a listener object can receive
event notifications from multiple sources, it is said to be a
multiplexing event receiver. For example, let’s say that our
Thermometer object was designed to track temperatures ...