Default methods
From APIDesign
(New page: An ability to add implementation of Java '''interface''' methods available since JDK8 is called default methods.) |
|||
| Line 1: | Line 1: | ||
| - | An ability to add implementation of [[Java]] '''interface''' methods available since [[JDK8]] is called [[default methods]]. | + | An ability to add implementation of [[Java]] '''interface''' methods available since [[JDK8]] is called [[default methods]]. From one point of view, it is a useful concept (in case one paints itself 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 == | ||
| + | |||
| + | 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! | ||
| + | |||
| + | [[TBD]] | ||
Revision as of 13:48, 2 March 2018
An ability to add implementation of Java interface methods available since JDK8 is called default methods. From one point of view, it is a useful concept (in case one paints itself 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
