Default methods

From APIDesign

Revision as of 10:28, 5 March 2018 (edit) JaroslavTulach (Talk | contribs) ← Previous diff		Current revision (10:38, 5 March 2018) (edit) (undo) JaroslavTulach (Talk | contribs) (Redirecting to DefaultMethods)
(One intermediate revision not shown.)
Line 1:		Line 1:
-	An ability to add ('''default''') implementation for [[Java]] '''interface''' methods available since [[JDK8]] is called [[default methods]].	+	#REDIRECT [[DefaultMethods]]
-		+
-	== 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 - 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 [[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.	+
-		+
-	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]]	+

---

Current revision

1. REDIRECT DefaultMethods