Based on an article in Martin Fowler’s Bliki, an interesting discussion has started, roughly six months ago (have a look at the overview at Joe de Villa’s Blog).
To make it short – some people like to use a very reduced API for a programming language, others can’t get enough “comfort methods” and interfaces and the rest likes something in between these extremes.
OK – here’s my personal proposal in a howto-manner:
An API could support different levels of, let’s say, “feature sets”. E.g. there could be a “feature set” with an identifier like “REDUCED”-“BASIC”-“NORMAL”, or just “1”-“2”-“3” and so forth.
The implementation of such “feature sets” could be implemented in Java with annotations e.g.
@feature-set BASIC
public void doSomething() { /* ... */ }
etc.
A developer now should have the chance to decide which “feature set” to use. How could she/he do this?
On the one hand, the compiler could support an argument that e.g. checks that only those methods are used that match the specified API “feature set” interfaces, classes, methods etc.
On the other hand, the IDE could support the developer in specifiying the API’s “feature set” and then display only the matching interfaces, classes, methods etc.
In my opinion an interface for programming is basically adressed to humans. If so, the “taste” and the experience of human programmers can differ extremely. So why should the API not allow the human programmer to select the range of features of it?
That such “feature sets” are feasible, is clearly shown with the Eclipse Mylar project.
Here, very individual “feature highlighters” are built based on single tasks and the dynamik activities of the programmer. Following this approach, one could even think giving programmers the ability to define their own, individual “feature sets” for a common API.
What do you think?
Schreibe einen Kommentar