[[Category:APIDesignPatterns:Anti]] [[Category:APIDesignPatterns:Clarity]] [[Category:APIDesignPatterns:Evolution]]

[[Category:APIDesignPatterns]] [[Category:APIDesignPatterns:Clarity]] [[Category:APIDesignPatterns:Evolution]]

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

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

== [[JavaBean]] Listener and Adapter ==

=== [[JavaBean]] Listener and Adapter ===

Do you remember the classical [[JavaBean]] pattern called ''listener'' and its associated ''adapter''? Imagine for example {{JDK|java/awt/event|MouseListener}} and {{JDK|java/awt/event|MouseAdapter}}. The pair of types used to be created to save users from always implementing all the ''listener'' methods and offer them to save some typing by rather using the adapter. Turns out [[DefaultMethods]] allow us to merge these two types into one:

Do you remember the classical [[JavaBean]] pattern called ''listener'' and its associated ''adapter''? Imagine for example {{JDK|java/awt/event|MouseListener}} and {{JDK|java/awt/event|MouseAdapter}}. The pair of types used to be created to save users from always implementing all the ''listener'' methods and offer them to save some typing by rather using the adapter. Turns out [[DefaultMethods]] allow us to merge these two types into one:

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

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

== Why? ==

=== 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 or unless it never returns or runs too long - e.g. all the usual warnings when calling foreign code are applicable) 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.

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 or unless it never returns or runs too long - e.g. all the usual warnings when calling foreign code are applicable) 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.

then [[DefaultMethods|all the arguments]] against using these [[DefaultMethods]] would apply again. It would again be impossible to distinguish between methods having default implementation or [[DefaultMethods]] overridden with intention to keep the default implementation.

then [[DefaultMethods|all the arguments]] against using these [[DefaultMethods]] would apply again. It would again be impossible to distinguish between methods having default implementation or [[DefaultMethods]] overridden with intention to keep the default implementation.

== Up Side Down ==

=== 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.

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 or unless it never returns or runs too long - e.g. all the usual warnings when calling foreign code are applicable) 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.

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 or unless it never returns or runs too long - e.g. all the usual warnings when calling foreign code are applicable) 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.

There is a necessary condition for that: such methods have to return '''void'''. If the methods returned anything observable, then we'd be back in the [[DefaultMethods]] situation. If the default body would like look like this:

There is a necessary condition for that: such methods have to return '''void'''. If the methods returned anything observable, then we'd be back in the [[DefaultMethods]] situation. If the default body would look like this:

<source lang="java">

<source lang="java">

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 or unless it never returns or runs too long - e.g. all the usual warnings when calling foreign code are applicable) 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.

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 or unless it never returns or runs too long - e.g. all the usual warnings when calling foreign code are applicable) 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.

There is a necessary condition for that: such methods have to return '''void'''. If the methods returned anything observable, then we'd be back in the [[DefaultMehtods]] situation. If the default body would like look like this:

There is a necessary condition for that: such methods have to return '''void'''. If the methods returned anything observable, then we'd be back in the [[DefaultMethods]] situation. If the default body would like look like this:

<source lang="java">

<source lang="java">

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 or unless it never returns or runs too long - e.g. all the usual warnings when calling foreign code are applicable) 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.

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 or unless it never returns or runs too long - e.g. all the usual warnings when calling foreign code are applicable) 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.

There is a necessary condition for that: such methods have to return '''void'''. If the methods returned anything observable, then the exception wouldn't apply. If the default body would like look like this:

There is a necessary condition for that: such methods have to return '''void'''. If the methods returned anything observable, then we'd be back in the [[DefaultMehtods]] situation. If the default body would like look like this:

<source lang="java">

<source lang="java">

== Why? ==

== 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 or unless it never returns or runs too long - e.g. usual warnings when calling foreign code apply here) 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.

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 or unless it never returns or runs too long - e.g. all the usual warnings when calling foreign code are applicable) 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.

There is a necessary condition for that: such methods have to return '''void'''. If the methods returned anything observable, then the exception wouldn't apply. If the default body would like look like this:

There is a necessary condition for that: such methods have to return '''void'''. If the methods returned anything observable, then the exception wouldn't apply. If the default body would like look like this:

== [[JavaBean]] Listener and Adapter ==

== [[JavaBean]] Listener and Adapter ==

Do you remember the classical [[JavaBean]] pattern called ''listener'' and its associated ''adapter''? Imagine for example {{JDK|java/awt/event|MouseListener}} and {{JDK|java/awt/event|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:

Do you remember the classical [[JavaBean]] pattern called ''listener'' and its associated ''adapter''? Imagine for example {{JDK|java/awt/event|MouseListener}} and {{JDK|java/awt/event|MouseAdapter}}. The pair of types used to be created to save users from always implementing all the ''listener'' methods and offer them to save some typing by rather using the adapter. Turns out [[DefaultMethods]] allow us to merge these two types into one:

<source lang="java">

<source lang="java">

</source>

</source>

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

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

== Why? ==

== Why? ==

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

Recently I tried to apply the [[DefaultMethods]] [[API Design]] warning to work done by my colleagues and they (obviously) objected. That's OK, they object 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 {{JDK|java/awt/event|MouseListener}} and {{JDK|java/awt/event|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:

Do you remember the classical [[JavaBean]] pattern called ''listener'' and its associated ''adapter''? Imagine for example {{JDK|java/awt/event|MouseListener}} and {{JDK|java/awt/event|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:

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!

Recently I tried to apply the [[DefaultMethods]] [[API Design]] warning to work done by my colleagues and they (obviously) objected. That's OK, they object 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 {{JDK|java/awt/event|MouseListener}} and {{JDK|java/awt/event|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:

Do you remember the classical [[JavaBean]] pattern called ''listener'' and its associated ''adapter''? Imagine for example {{JDK|java/awt/event|MouseListener}} and {{JDK|java/awt/event|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:

</source>

</source>

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 [[DefaultMethods|all the arguments]] against using these [[DefaultMethods]] would apply again. It would again be impossible to distinguish between methods having default implementation or [[DefaultMethods]] overridden with intention to keep the default implementation.

== Up Side Down ==

== Up Side Down ==