Modular library

From APIDesign

Revision as of 21:31, 8 May 2012 by JaroslavTulach (Talk | contribs)
Jump to: navigation, search

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.

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 M-N and 1-N case. However, without having experience with the M-N case, they fallback to most obvious solution: Use abstract classes. While extending abstract classes 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 then to admit they are distinct. Then one has to accept design style suitable for modular library. As it is clear that the M-N case is a superset of 1-N case, I'd like to ask: Why not use the M-N style all the time?

Personal tools
buy