'. '

Default Listener Methods

From APIDesign

(Difference between revisions)
Jump to: navigation, search
Line 13: Line 13:
</source>
</source>
-
Such listener type is both a ''listener'' as well as an ''adaptor'' and there is nothing wrong with that! Why does the above philippic against using [[DefaultMethods]] in an [[API]] doesn't apply? The code that runs after one of the listener methods isn't (unless an unexpected [[exception]] happens) influenced by the code in the method - e.g. it shouldn't matter what the method does and thus adding new method with default empty implementation seems to be OK. The necessary condition for that is the fact that the methods return '''void''' - if they returned anything observable - e.g. the default body would something like:
+
Such listener type is both a ''listener'' as well as an ''adaptor'' and there is nothing wrong with that!
 +
 
 +
== Why? ==
 +
 
 +
Why does the [[DefaultMethods|philippic]] against using [[DefaultMethods]] in an [[API]] doesn't apply? The code that runs after one of the listener methods isn't (unless an unexpected [[exception]] happens) influenced by the code in the method - e.g. it shouldn't matter what the method does and thus adding new method with default empty implementation seems to be OK. The necessary condition for that is the fact that the methods return '''void''' - if they returned anything observable - e.g. the default body would something like:
<source lang="java">
<source lang="java">
Line 23: Line 27:
then all the above arguments against these methods would apply again, as it would be impossible to distinguish between methods having default implementation or methods overridden with intention to keep the default implementation.
then all the above arguments against these methods would apply again, as it would be impossible to distinguish between methods having default implementation or methods overridden with intention to keep the default implementation.
 +
 +
== Up Side Down ==
Thanks Dušane for pointing the ''listener'' case out! As mentioned in [[TheAPIBook]], slight change in the initial situation may turn the final advice up side down. Thus I gladly (have to) admit: using [[DefaultMethods]] in listener [[JavaBean]] pattern is perfectly fine.
Thanks Dušane for pointing the ''listener'' case out! As mentioned in [[TheAPIBook]], slight change in the initial situation may turn the final advice up side down. Thus I gladly (have to) admit: using [[DefaultMethods]] in listener [[JavaBean]] pattern is perfectly fine.

Revision as of 06:31, 19 April 2018

Recently I tried to apply the DefaultMethods API Design warning to work done by my colleagues and they (obviously) objected. That's OK, that happens all the time, but the worst thing this time was: they were right!

Do you remember the classical JavaBean pattern called listener and its associated adapter? Imagine for example MouseListener and MouseAdapter. The pair of classes was created to save users from always implementing all the listener methods and rather use the adapter. Turns out DefaultMethods allow us to merge these two types into one:

public interface MouseListener extends EventListener {
    public default void mouseClicked(MouseEvent e) {}
    public default void mousePressed(MouseEvent e) {}
    public default void mouseReleased(MouseEvent e) {}
    public default void mouseEntered(MouseEvent e) {}
    public default void mouseExited(MouseEvent e) {}
}

Such listener type is both a listener as well as an adaptor and there is nothing wrong with that!

Why?

Why does the philippic against using DefaultMethods in an API doesn't apply? The code that runs after one of the listener methods isn't (unless an unexpected exception happens) influenced by the code in the method - e.g. it shouldn't matter what the method does and thus adding new method with default empty implementation seems to be OK. The necessary condition for that is the fact that the methods return void - if they returned anything observable - e.g. the default body would something like:

/** @return true to "consume" the event */
    public default boolean mouseExited(MouseEvent e) {
      return false;
    }

then all the above arguments against these methods would apply again, as it would be impossible to distinguish between methods having default implementation or methods overridden with intention to keep the default implementation.

Up Side Down

Thanks Dušane for pointing the listener case out! As mentioned in TheAPIBook, slight change in the initial situation may turn the final advice up side down. Thus I gladly (have to) admit: using DefaultMethods in listener JavaBean pattern is perfectly fine.

Personal tools