Final interface
From APIDesign
(→Why it works?) |
|||
| Line 9: | Line 9: | ||
However most of the more complex [[Java]] applications were not satisfied with the default [[Java]] parser and needed to include different implementation. And hence the problems began - when one had implementation of [[DOM]]3 provided as a [[library]], but the [[DOM]]2 [[API]] provided by the [[JDK]], the linkage problems were endless. [[JDK]]'s distribution of [[DOM]]2 and parsers and applications relying on [[DOM]]3 (which contains incompatible interfaces from [[ProviderAPI|provider point of view]]) just created a unsolvable mess. | However most of the more complex [[Java]] applications were not satisfied with the default [[Java]] parser and needed to include different implementation. And hence the problems began - when one had implementation of [[DOM]]3 provided as a [[library]], but the [[DOM]]2 [[API]] provided by the [[JDK]], the linkage problems were endless. [[JDK]]'s distribution of [[DOM]]2 and parsers and applications relying on [[DOM]]3 (which contains incompatible interfaces from [[ProviderAPI|provider point of view]]) just created a unsolvable mess. | ||
| - | == | + | == When it works? == |
| - | + | The above problems can be slightly mitigated if one has good runtime support for [[modularity]] and this may be the reason why the [[vendor library]] seems to be very popular in [[OSGi]] world. The [[API]] part can request proper implementation and the [[OSGi]] container will select the right one. However it needs to be stated that this works only in [[One to Many]] mode - e.g. when there is a single provider of the [[DOM]] parser and many users of the [[DOM]] parsing API. Then one can use [[OSGi]] [RangeDependencies]] to make sure the implementation has closer [[proximity]] than users of the [[DOM]] [[API]]. | |
| + | |||
| + | Once you end up with multiple [[DOM]] parser implementations in your application (like a large and [[modular]] app like [[NetBeans]] did) - e.g. you enter [[Many to Many]] relationship, no close [[proximity]] is going to safe you. The only saving point is to adhere to best [[APIDesign]] practice and separate [[ClientAPI]] from [[ProviderAPI]]s. As such [[I]] am going to include [[final interface]] in [[APIDesign]] anti patterns although [[I] am sure [[OSGi]] friends will never try to understand why. | ||
| + | |||
| + | == Enforcing [[final interface]] During Compilation == | ||
| + | |||
| + | [[TBD]] | ||
| + | |||
| + | |||
| + | [[Category:APIDesignPatterns]] [[Category:APIDesignPatterns:Anti]] [[Category:APIDesignPatterns:Evolution]] | ||
Revision as of 07:44, 4 February 2015
Final interface is a pattern often used in vendor library style API design. It marks a Java interface in an API as final (either in Javadoc or elsewhere TBD) with the evolution plan to expand it incompatibly (from the point of implementers). The hope is that nobody except the implementers will ever implement such interface.
Why it does not work?
DOM2 vs. DOM3 problems are famous. The interfaces in DOM Java API were made Final interface, but as the XML specification was still evolving it soon turned out the original interfaces are not satisfactory. The XML introduced namespaces and the Java DOM API needed to adopt to it. How can one do it with Final interfaces? Well, you break backward compatibility for those who implement the interface - and there were many DOM2 parsers, as at certain point in time it was very popular to write own's XML parser.
If one worked only with the standard XML parser provided by the JDK itself together with the DOM API - everything worked fine. Of course, because of closest possible proximity! When you package your [[API] with (the only) implementation you don't have evolution and versioning problems - the proximity is so intimate, you don't have to think about versioning.
However most of the more complex Java applications were not satisfied with the default Java parser and needed to include different implementation. And hence the problems began - when one had implementation of DOM3 provided as a library, but the DOM2 API provided by the JDK, the linkage problems were endless. JDK's distribution of DOM2 and parsers and applications relying on DOM3 (which contains incompatible interfaces from provider point of view) just created a unsolvable mess.
When it works?
The above problems can be slightly mitigated if one has good runtime support for modularity and this may be the reason why the vendor library seems to be very popular in OSGi world. The API part can request proper implementation and the OSGi container will select the right one. However it needs to be stated that this works only in One to Many mode - e.g. when there is a single provider of the DOM parser and many users of the DOM parsing API. Then one can use OSGi [RangeDependencies]] to make sure the implementation has closer proximity than users of the DOM API.
Once you end up with multiple DOM parser implementations in your application (like a large and modular app like NetBeans did) - e.g. you enter Many to Many relationship, no close proximity is going to safe you. The only saving point is to adhere to best APIDesign practice and separate ClientAPI from ProviderAPIs. As such I am going to include final interface in APIDesign anti patterns although [[I] am sure OSGi friends will never try to understand why.
Follow
