Tuesday, November 15, 2005

On interfaces

A concrete class may be seen as a comprehensive way of describing a set of objects sharing certain characteristics. These objects are said to be their instances.

An abstract class also describes comprehensively a set of objects. However, the objects in this set are not described in full. Rather, their description in full is always provided by one of the concrete classes which specialize the abstract class. Abstract classes, hence, correspond in terms of objects to the unions of the objects which are possible instances of their concrete specializations. Since it is always possible to provide a further concrete specialization of an abstract class, describing a whole new set of possible instances, abstract classes are, in a sense, open.

Classes, whether abstract or not, are always descriptions of objects. Hence, their identifiers are usually nouns or small noun phrases. E.g., Vehicle (abstract class) and Car (depending on the context, may either be concrete or abstract).

Interfaces should not be confused with abstract classes, though the lack of interfaces in some languages forces programmers to use abstract classes as an alternative. Interfaces represent abilities which objects may have. The abilities are supposed to be related to behaviour. Having a certain ability is usually insufficient to fully describe a possible, existing, object. Hence, interfaces usually represent partial abilities of objects. Objects may have multiple abilities. Since existing objects are always instances of concrete classes, their possession of certain abilities must be declared at the class level. Hence, classes implement interfaces. Multiple classes may implement the same interface, and multiple interfaces may be implemented by a single class.

Class specialization, or extension, may be seen as a two-way process. Firstly, the specialization implements the behaviour of the more general class, i.e., the more general class is seen merelly as an interface, whose abilities the specialization declares to provide. Secondly, the specialization inherits the implementation available in the more general class (which may or may not be complete, according to whether it is concrete or not - though specialization of concrete classes is not recomended).

It is the implementation of behaviour which provides the notion of sub-typing. Sub-typing allows dynamic polymorphism, which is thus (in a way, just) possible through interfaces. Sub-classing is sub-typing plus implementation sharing. In Java multiple sub-typing is possible, but multiple sub-classing is not.

Since interfaces declare behaviour, their identifiers should be adjectives (or adjective phrases) representing abilities. In the english language most of these adjectives end with the suffixes "-able" or "-ible", from the latin "-abilis", meaning "capable of". E.g., the classics Comparable or Clonable.

If your best choice for the identifier of some classe or interface does not fit with the above recomendations, then think again about your modelling: it is most likelly wrong.

Finally, yes. It is true. The name "interface" is not very good. One should say that a class "provides" a certain "behaviour" instead of simply saying that it "implements" a certain "interface". Even if the lack of support for programming by contract makes the explicit contracting of behaviour impossible, forcing the compiler to merely check whether... interfaces are implemented. Sigh...

From: Rambling about Java