Default methods
From APIDesign
| Line 1: | Line 1: | ||
| - | An ability to add ('''default''') implementation for [[Java]] '''interface''' methods available since [[JDK8]] is called [[default methods]]. From one point of view, it is a useful concept (in case one paints | + | An ability to add ('''default''') implementation for [[Java]] '''interface''' methods available since [[JDK8]] is called [[default methods]]. From one point of view, it is a useful concept (in case one paints himself into a corner by not following advices of [[TheAPIBook]]), but it also comes with drawbacks. In case you have published an [[API]] full of interfaces (like {{JDK|java/util|List}} that people use as [[ClientAPI]], you are going to welcome the ability to add few [[default methods]] to such interface (just like the [[JDK]] team did). |
== Increasing Fuzziness == | == Increasing Fuzziness == | ||
Revision as of 10:16, 5 March 2018
An ability to add (default) implementation for Java interface methods available since JDK8 is called default methods. From one point of view, it is a useful concept (in case one paints himself into a corner by not following advices of TheAPIBook), but it also comes with drawbacks. In case you have published an API full of interfaces (like List that people use as ClientAPI, you are going to welcome the ability to add few default methods to such interface (just like the JDK team did).
Increasing Fuzziness
However interface with default methods is fuzzier than pure interface (without any implementation). interface with some (default) implementation no longer clearly defines a contract - e.g. its use for ProviderAPI is no longer as sharp as it could be.
When somebody implements such interface, one can choose to implement the default methods or ignore them. That increases fuzziness. Moreover when we look at the concept from the evolution point of view, it may get even fuzzier.
Envision a pure interface defined in an initial version. Imagine the interface being implemented by various parties API users. Later the interface gets enriched with few default methods. When you look at an implementation of the interface which doesn't override the default methods: What can you conclude?
Either they don't implement the default methods as they weren't existing when the implementations were written - e.g. they compiled against original version of the API. Or they don't implement the default methods because they are happy with their default implementation. That may make (and does make) a difference! But it is impossible to separate these two cases apart!
Follow
