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 state of a programming language. For example for describing capabilities of Java, one would have 1.0 version. Later 1.1 version of the API would add support for inner classes. Few years after that 1.4 version would add assert keyword. Subsequent 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, extended interface for this language v2.0:

does not exists: visitor.cleanversion.v2

The new visitor interface in fact does not need to extend the one for previous version. For example it is possible to create another version that defines new interface that replaces methods dealing with 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 patterns where usage of Java interfaces (and not classes) is more than appropriate.