Proximity

From APIDesign

Revision as of 22:44, 27 April 2012

Often there is more than one type of "users" of an API. As 3SidesToEveryAPI explains, there is always at least the [[API] author point of view and API user point of view. But from time to time there may be even more parties involved in design and consumption of an API. Depending on how closely related to the API specification those are, we can group them into API proximity categories.

The most distant group of users for the users of the ClientAPI - e.g. those that make calls into existing API objects, but those that don't implement them. In spite there are differences among this group as well, let's ignore them for now.

Zero to N

Some libraries, let's name them simple libraries, have just one implementation. The designer that defines what the API should do also implements it. Obviously, the proximity between the API and the provider of the implementation is almost zero - it is the same person or the same team.

Simple libraries are usually self contained. They combine the API specification together with the implementation. There is no reason, no way to plug into the library and change the way it behaves (for other clients of its API). Examples of such simple library include most of java.util package (with classes like ArrayList or Collections)), or other utility classes like Math class.

Of course, there may be some attempts to re-implement these simple libraries (like GNU Classpath or Harmony show), but those are usually licensing driven efforts, not purely technical ones.

Especially when the simple library is available as open source. It is much easier to contribute back than to fork. If there is some flaw in the library, it seems easier to create an API Patch and donate it back to the simple library owners. In general, there is little to no reason to re-implement simple library APIs.

1 to N

After visiting OSGiCon I can see the value of this category, but yes, I have to admit I feel uneasy. But that is OK, people are supposed to feel uneasy when they have to accept new ideas.

Talk about: ModularLibrary with 1-N and N-M proximities.

M to N

Arity.

TBD