- Design Patterns
- A Pattern Example
- Don't Be Misled by Design Patterns
- An Aside on MouseAdapter
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Don't Be Misled by Design Patterns
The names of design patterns are extremely general, but they tend to have fairly specific definitions—often with a lengthy list of requirements. That's a double-edged sword. The upside is that when you're designing a class to match a particular design pattern, actually fulfilling that list of requirements helps ensure that you're taking advantage of the design pattern. Remember that the whole point of a design pattern is to try to communicate the wisdom of experienced programmers who have already created a class similar to the one you're creating, and have already made the mistake you're about to make.
But there's another side to that. Many of the design patterns have names that are extremely general (Adapter, State, and Mediator being just three examples) but fairly specific definitions. The names can reasonably apply to many classes that don't fit the pattern. For example, take a look at this class:
/ ** An abstract adapter class for receiving mouse events.
* The methods in this class are empty. This class exists as
* convenience for creating listener objects.
* ...
*/
public abstract class MouseAdapter implements MouseListener {
/**
* Invoked when the mouse has been clicked on a component.
*/
public void mouseClicked(MouseEvent e) {}
...
}
Does this fit the definition of Adapter? The definition reads as follows: "Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces."
That doesn't really sound like what this class is doing. The structure of an Adapter (as a UML diagram) looks like Figure 1, whereas the UML diagram of MouseAdapter looks like Figure 2.
)
Figure 1 The diagram of a classic Adapter.
)
Figure 2 The MouseAdapter.
These don't match because, in and of itself, the MouseAdapter isn't adapting anything to the MouseListener interface. You could create a subclass of MouseAdapter that is an Adapter, as in Figure 3.
)
Figure 3 Making a real Adapter out of MouseAdapter.
Here, MouseAdapter and MouseHandler together form an Adapter from OldClass to MouseListener.
This doesn't mean that MouseAdapter is a bad class, or even that it's badly named. It doesn't fit the pattern of an Adapter according to the Design Patterns book, but it would be presumptuous to claim that this was the only meaning of adapter.
We all have our own little languages, in programming as well as in speech, that suit our needs. The Design Patterns book attempts to standardize the language, but like any dictionary it can only give you what some experts expect a word to mean, not what it necessarily means to the person who speaks the word to you.
MouseAdapter isn't exactly a great name. It really isn't an adapter, even in the general sense, since it doesn't adapt anything. It's more like a MouseListenerAdapterBasis or MouseListenerAdapterUtility or MouseListenerAdapterSupport, but those are kind of verbose. It's certainly convenient to say that MouseHandler is a "mouse adapter," and that's true in two different senses: It adapts OldClass to the MouseListener class, and it "is a" MouseAdapter in the same sense that JPanel "is a" JComponent by virtue of being a subclass.
So we'll just accept the name MouseAdapter and get on with our lives.