Default methods
From APIDesign
(→Increasing Fuzziness) |
|||
| Line 3: | Line 3: | ||
== Increasing Fuzziness == | == 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. | + | However '''interface''' with [[default methods]] is [[fuzzier|clarity]] 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. | 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. | ||
Revision as of 10:11, 5 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 clarity 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
