ClearDefinitionOfVersion

From APIDesign

Sometimes API designers need to specify a set of methods that others have to implement. Yet the designers know that the set is going to be valid for just a limited amount of releases. It is clear that in some future release, the set of methods will have to change.

This commonly happens when one needs a to capture a language. For example for describing capabilities of Java, one would have 1.0 version, then 1.1 version of the interface would add support for inner classes. 1.4 version would add assert keyword. Version 1.5 would have support for generics and other features, etc.

As an example, imagine that one needs to define a visitor for language that supports numbers and plus operation. One can do it with interface Visitor10:

does not exists: visitor.cleandefinitionofversion

Later, when the language is extended to also support Minus operation one defines a new interface for this language v2.0:

does not exists: visitor.cleanversion.v2

And later, in another version, one can even define new interface that replaces integer Numbers with Real ones:

does not exists: visitor.nonmonotonic.visitor

By using separate interfaces for each version, one clearly communicates to the API users willing to work with (for example) version 2.0 what set of methods must be implemented.

This is one of the examples where usage of Java interface (and not classes) is more than appropriate.