Let's take our example above and consider an application that needs a font selector. To add this functionality, we would need to use three separate components to gather the name, style, and point size of the font. The application's event-handling code would, of course, need to include filters for all three components. That's a whole lot of internal event handling to keep track of. If instead we created a distinct font selector component, this inherently internal event handling would be hidden. The application would only need to catch a font selector event object, and the target of the event would be the instantiated font selector object itself -- a much cleaner approach.
Clearly, an important feature of custom components is this ability to hide details from your application, but the decision to write custom components also should be driven by the reusability factor. When you find yourself in need of a particular functionality over and over again, it would make sense to create a custom component for this task. Taken one step further, you can combine specialized user interface elements that are used repeatedly into a custom component package, making the classes easy to reuse, especially among a group of developers.
Now, before you go writing customized code for every possible variation of a component, I must mention one caveat in regard to custom components. When you are developing applets, your custom component classes will have to be downloaded because they are not part of the core API available locally to all Java virtual machines. As long as your applet doesn't use a lot of custom classes, you've got nothing to worry about, but if optimal download time is critical, make sure you thoroughly consider the necessity of enhanced functionality.
As I mentioned earlier, one really nice advantage of writing specialized components is that your application-level event handling
will be much cleaner. The Component superclass has a method, postEvent, that you can use to propagate an event to the parent container. This Event object will contain all of the information that the container needs to determine the details of the event.
The Event object has several variables (target, arg, date, x, and y, among others) for determining such facts as which component generated the event and the time of the action. The arg variable is essentially the "message" of the event. This field is of type Object, which means that it can hold any type of information. The Checkbox class, for example, uses this field to store a boolean corresponding to the state of the checkbox, which allows it to notify the application of its new state. In terms of a font
selector, the message this component needs to get to the application is the Font object chosen by the user.