Redirecting to DefaultMethods
←Older revision | Revision as of 10:38, 5 March 2018 | ||
Line 1: | Line 1: | ||
- | + | #REDIRECT [[DefaultMethods]] | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + |
Redirecting to DefaultMethods
←Older revision | Revision as of 10:38, 5 March 2018 | ||
Line 1: | Line 1: | ||
- | + | #REDIRECT [[DefaultMethods]] | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + |
←Older revision | Revision as of 10:30, 5 March 2018 | ||
Line 5: | Line 5: | ||
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]]. | 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]]. | ||
- | + | Later one needs to add new methods into the [[ClientAPI]] side of the contract. In such situation one is going to welcome [[default methods]] as a nice way to help one get ''out of the corner''. By adding [[default methods]] one can 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 == | == Increasing Fuzziness == |
←Older revision | Revision as of 10:28, 5 March 2018 | ||
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. |
←Older revision | Revision as of 10:27, 5 March 2018 | ||
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 | + | 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 [[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). | ||
+ | |||
+ | 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 == | == Increasing Fuzziness == |
←Older revision | Revision as of 10:17, 5 March 2018 | ||
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 himself into a corner by not following advices of [[TheAPIBook]]) | + | 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]] when designing the first version of the [[API]]). However the concept of [[default methods]] 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 == |
←Older revision | Revision as of 10:16, 5 March 2018 | ||
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 == |
←Older revision | Revision as of 10:16, 5 March 2018 | ||
Line 1: | Line 1: | ||
- | An ability to add implementation | + | 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 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 == | == Increasing Fuzziness == |
Increasing Fuzziness
←Older revision | Revision as of 10:12, 5 March 2018 | ||
Line 5: | Line 5: | ||
However '''interface''' with [[default methods]] is [[clarity|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 [[clarity|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. | + | 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? | 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? |
Increasing Fuzziness
←Older revision | Revision as of 10:12, 5 March 2018 | ||
Line 3: | Line 3: | ||
== Increasing Fuzziness == | == Increasing Fuzziness == | ||
- | However '''interface''' with [[default methods]] is [[ | + | However '''interface''' with [[default methods]] is [[clarity|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. | 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. |
Increasing Fuzziness
←Older revision | Revision as of 10:11, 5 March 2018 | ||
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. |