views:

75

answers:

4

I have an interface -- "EventHandler" -- that declares several methods.

public interface EventHandler {
    void handleEvent1();

    void handleEvent2();

    void handleEvent3();

    void handleEvent4();
}

I also have a class -- "EventHandlerAdapter" -- that implements EventHandler. However, it doesn't actually "implement" anything. The point is, if another class wants to implement EventHandler, but not all of its methods, it can simply extend EventHandlerAdapter and only override the methods it wants to.

public class EventHandlerAdapter implements EventHandler {
    public void handleEvent1() {}

    public void handleEvent2() {}

    public void handleEvent3() {}

    public void handleEvent4() {}
}

I've seen something like this on more than one occasion. The name "EventHandlerAdapter" suggests to me that it is an example of the adapter pattern... but is it really? I thought the point of an adapter was to translate an existing implementation into something else. I don't see how this is the case here.

If it isn't an example of the adapter pattern, what is it? Surely something like this has been identified.

+2  A: 

You are right, this is not an example of the Adapter design pattern, rather a trivial default implementation of the interface. I would rename it to DefaultEventHandler, EmptyEventHandler or GenericEventHandler.

Péter Török
This would not be consistent with the Java API.
Erick Robertson
and I guess you would name the Java classes in a similar fashion as well :) (+1)
Bozho
@Erick, I just learned from the other answers about this naming convention - good to know :-) I still maintain though that `DefaultEventHandler` et al. is a better name than `EventHandlerAdapter` because it is not ambiguous. People not versed in Java event handling conventions are puzzled by this Adapter, while IMHO the other camp would not have problems understanding a Default* class name. Is it better to stick to a naming convention even if it is ambiguous, or is it better to fix it? I prefer the latter, but of course other people may have different preferences.
Péter Török
@Erick, note also that there are several well known examples of bad design / naming decisions within the Java API, so it is not always the best example to learn from and to adhere to :-)
Péter Török
People should get versed in Java event handling if they're going to be working with it. Anyone versed in it will immediately recognize the Adapter name and know what it does. This is the advantage of sticking with an established naming convention. I don't find it ambiguous at all.
Erick Robertson
@Erick, good for you...
Péter Török
+5  A: 

No, this is not an example of an Adapter Pattern, as defined here:

http://en.wikipedia.org/wiki/Adapter_pattern

However, in Java Event handling, the term Adapter is frequently used as you mentioned. Even though the word "Adapter" is the same in both, they do not refer to the same thing. The Adapters that appear in the java.awt.event package are there to make it easy to create an event handler that handles only one method without having to write a bunch of empty methods. They are only shortcut classes.

The Java Event API typically has consistent naming for these classes. When there is a SomeEvent event class, there is a SomeListener interface to listen to the event and a SomeAdapter class implementing the listener interface with empty methods. Not all events have all three of these parts, but there is consistency in the naming and function of the three.

In the example you provided, I would rename the class EventAdapter to be consistent with the existing Java API.

Erick Robertson
yes, consistency is a good thing ;)
Bozho
After some thinking, I've decided that something like "AbstractEventHandler" is more appropriate. It may not be consistent, but really, is the Java API itself even consistent?
someguy
@someguy, the name Abstract* implies that the class is `abstract`, thus it _must_ be subclassed in order to be used. E.g. the Java Collection Framework contains several such classes. While in this case, the class is usable as it is, and it _may_ be subclassed. So to me the name would be misleading.
Péter Török
@Péter Török The class *shouldn't* be used directly imo. Initially, I was going to declare the constructor as private so that people wouldn't use the class directly as a "nop" of some sort. Looking at the java.awt.event API reminded me that I could simply declare the class as abstract... silly me :P.
someguy
@someguy, in this case there is no problem with the naming indeed.
Péter Török
+2  A: 

You are right, it's not an example of adapter pattern but a widely adopted convention to have "default empty for " called "adapters"

For example java UI APIs often provide such adapters for MouseListener interfaces.

Manuel Selva
+2  A: 

The AWT has a lot of implementations of interfaces which they call "Adapter", like 'MouseAdapter', 'FocusAdapter'. And no, they are not implementations of the Adapter pattern. They are convenience classes, I'd simply call them stubs.

Andreas_D