Modular library

From APIDesign

(Difference between revisions)
Jump to: navigation, search
Current revision (13:29, 7 May 2019) (edit) (undo)
 
(7 intermediate revisions not shown.)
Line 1: Line 1:
-
In some cases one needs to have multiple [[ProviderSPI|different implementations]] of some [[API]] being used at once. These implementations are being written in [[distributed development]] environment, they may not be written against the same version of the [[library]] at all. The [[proximity]] between the [[API]] and the implementations is very weak. As a result trying to mimic the principles used while designing [[vendor library]] will not work.
+
In some cases one needs to have multiple [[ProviderAPI|different implementations]] of some [[API]] being used at once. These implementations are being written in [[distributed development]] environment, they may not be written against the same version of the [[library]] at all. The [[proximity]] between the [[API]] and the implementations is very weak. As a result trying to mimic the principles used while designing [[vendor library]] will not work and even [[semantic versioning]] may be too restricting.
-
In case of [[modular library]] the [[proximity]] of the [[API]] designer and the implementers is almost the same as the [[proxymity]] of the [[API]] designer and the [[ClientAPI|users of the API]]. This requires the [[API]] vendor to prepare [[evolution]] plan for both - the [[ClientAPI]] as well as [[ProviderAPI]].
+
In case of [[modular library]] the [[proximity]] of the [[API]] designer and the implementers is almost the same as the [[proximity]] of the [[API]] designer and the [[ClientAPI|users of the API]]. This requires the [[API]] vendor to prepare [[evolution]] plan for both - the [[ClientAPI]] as well as [[ProviderAPI]].
-
As my discussion at [[OSGiCon]] revealed, people facing this situation realize the difference between the [[Modular library|M-N]] and [[Vendor library|1-N]] case. However, without having [[experience]] with the [[Modular library|M-N]] case, they fallback to most obvious solution: Use ''abstract classes''. While extending ''abstract classes'' is definitely more compatible than [[final interface|extending interfaces]], it can never be 100% safe. The safest solution is to [[APIvsSPI|separate API for clients and providers]] (taken to extreme, while demonstrating all benefits, in the extensible [[visitor]] case).
+
As my discussion at [[OSGiCon]] revealed, people facing this situation realize the difference between the [[Modular library|Many to Many]] and [[Vendor library|One to Many]] and [[Semantic versioning|Few to Many]] cases. However, without having [[experience]] with the [[Modular library|Many to Many]] case, they fallback to most obvious solution: Use of [[abstract class]]es (or these days interfaces with [[DefaultMethods]]). While extending [[abstract class]]es with new methods is definitely more compatible than [[final interface|extending interfaces]], it can never be 100% safe. The safest solution is to [[APIvsSPI|separate API for clients and providers]] (taken to extreme, while demonstrating all benefits, in the extensible [[visitor]] case).
-
Weak [[proximity]] changes everything. An [[API]] designer can simplify its life by claiming all [[ProviderAPI|providers]] are [[proximity|close]]. However sometimes there is just no way around then to admit they are [[proximity|distinct]]. Then one has to accept design style suitable for [[modular libraries]]. As it is clear that the [[modular library|M-N]] case is a superset of [[vendor library|1-N]] case, I'd like to ask: Why not use the [[modular library]] style all the time?
+
Weak [[proximity]] changes everything. An [[API]] designer can simplify its life by claiming all [[ProviderAPI|providers]] are [[proximity|close]]. However sometimes there is just no way around than to admit they are [[proximity|distant]]. Then the best thing to do is to accept the design style suitable for [[modular library]].

Current revision

In some cases one needs to have multiple different implementations of some API being used at once. These implementations are being written in distributed development environment, they may not be written against the same version of the library at all. The proximity between the API and the implementations is very weak. As a result trying to mimic the principles used while designing vendor library will not work and even semantic versioning may be too restricting.

In case of modular library the proximity of the API designer and the implementers is almost the same as the proximity of the API designer and the users of the API. This requires the API vendor to prepare evolution plan for both - the ClientAPI as well as ProviderAPI.

As my discussion at OSGiCon revealed, people facing this situation realize the difference between the Many to Many and One to Many and Few to Many cases. However, without having experience with the Many to Many case, they fallback to most obvious solution: Use of abstract classes (or these days interfaces with DefaultMethods). While extending abstract classes with new methods is definitely more compatible than extending interfaces, it can never be 100% safe. The safest solution is to separate API for clients and providers (taken to extreme, while demonstrating all benefits, in the extensible visitor case).

Weak proximity changes everything. An API designer can simplify its life by claiming all providers are close. However sometimes there is just no way around than to admit they are distant. Then the best thing to do is to accept the design style suitable for modular library.

Retrieved from "http://wiki.apidesign.org/wiki/Modular_library"
Personal tools
buy