Default methods
From APIDesign
Line 3: | Line 3: | ||
== Useful? == | == Useful? == | ||
- | From one point of view, it is a useful concept. Especially if one paints himself into a corner by not following advices of [[TheAPIBook]] when designing the first version of the [[API]]. If one mixes [[APIvsSPI|client and provider]] [[API]] into one type - like {{JDK|java/util|List}}, then one gets into trouble. On one side people call into the type (e.g. use it as [[ClientAPI]]). On the other hand, they also implement it - like {{JDK|java/util|ArrayList}} - but also numerous custom implementations written by developers around the globe | + | From one point of view, it is a useful concept. Especially if one paints himself into a corner by not following advices of [[TheAPIBook]] when designing the first version of the [[API]]. If one mixes [[APIvsSPI|client and provider]] [[API]] into one type - like {{JDK|java/util|List}}, then one gets into trouble. On one side people call into the type (e.g. use it as [[ClientAPI]]). On the other hand, they also implement it - like {{JDK|java/util|ArrayList}} - but also numerous custom implementations written by developers around the globe - e.g. use it as [[ProviderAPI]]. |
When you get into situation you are going to welcome [[default methods]] as a nice way to help you get out of the corner. Being able to add [[default methods]] is then welcomed ability to enhance the [[ClientAPI]] part of the interface, while keeping (most of) the compatibility for those who implement the '''interface'''. However the concept of [[default methods]] also comes with drawbacks. | When you get into situation you are going to welcome [[default methods]] as a nice way to help you get out of the corner. Being able to add [[default methods]] is then welcomed ability to enhance the [[ClientAPI]] part of the interface, while keeping (most of) the compatibility for those who implement the '''interface'''. However the concept of [[default methods]] also comes with drawbacks. |
Revision as of 10:28, 5 March 2018
An ability to add (default) implementation for Java interface methods available since JDK8 is called default methods.
Useful?
From one point of view, it is a useful concept. Especially if one paints himself into a corner by not following advices of TheAPIBook when designing the first version of the API. If one mixes client and provider API into one type - like List, then one gets into trouble. On one side people call into the type (e.g. use it as ClientAPI). On the other hand, they also implement it - like ArrayList - but also numerous custom implementations written by developers around the globe - e.g. use it as ProviderAPI.
When you get into situation you are going to welcome default methods as a nice way to help you get out of the corner. Being able to add default methods is then welcomed ability to enhance the ClientAPI part of the interface, while keeping (most of) the compatibility for those who implement the interface. However the concept of default methods also comes with drawbacks.
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!