Warning

Most introductory books are written by authors who do not understand the model-view-controller pattern and the proper use of callbacks. Callbacks are not supported in C or C++ because there is no concept of procedures as data objects (simply passing a pointer to a procedure does not work!). As a result, textbook authors with a C/C++ background are accustomed to using ugly alternatives to callbacks which they continue to use in the context of Java. A common and particularly onerous abuse of the Java callback interface is implementing the requisite listener interfaces by methods in the main viewer class, which is typically a frame or an applet. This approach limits each event category to a single callback, e.g, one callback method for all buttons which is coded in the main viewer class.

This approach has four serious disadvantages.

• First, to determine which component produced a given event, the viewer class must uniquely label each event source (or maintain a table of event references).
• Second, when the listener receives an event, it must classify the event source using a sequence of tests or look it up in a table to determine what block of code should be used to process the event.
• Third, the code to process the event embedded in the view relies on the interface provided by the application, corrupting the model-view-controller decomposition.
• Fourth, if another graphical component in the same category is added to the view (e.g, a new button) then the code for the callback method for that event category must be modified.

Since the command pattern (procedures as data objects) completely eliminates this mess, the ``view class as listener'' approach to event processing is indefensible. Nevertheless, it is widely taught even by some reputed ``experts'' on Java programming. In fact, I am familiar with only one popular Java book that teaches good programming practice in conjunction with GUI programming, namely Thinking in Java by Bruce Eckel.