Interface-based programming

Interface-based programming defines the application as a collection of components, in which Application Programming Interface (API) calls between components may only be made through abstract interfaces, not concrete classes. Instances of classes will generally be obtained through other interfaces using techniques such as the Factory pattern.

This is claimed to increase the modularity of the application and hence its maintainability. However, some caution is warranted – merely splitting an application into arbitrary components communicating via interfaces does not in itself guarantee low coupling or high cohesion, two other attributes that are commonly regarded as key for maintainability.

An interface-based architecture can be used when third parties – or indeed separate teams within the same organisation – develop additional components or plugins for an established system. The codebase of the Eclipse IDE is an example of interface-based programming. Eclipse plugin vendors just have to develop components that satisfy the interface specified by the parent application vendor, the Eclipse Foundation. Indeed, in Eclipse, even the original components such as the Java Development Tools are themselves plugins. This is somewhat like a mobile phone manufacturer specifying a mobile charger interface (pin arrangement, expected direct current voltage, etc.) and both the manufacturer and third parties making their own mobile phone chargers that comply with this standard interface specification.

Software evolution in interface-based programming

The use of interfaces to allow disparate teams to collaborate raises the question of how interface changes happen in interface-based programming. The problem is that if an interface is changed, e.g. by adding a new method, old code written to implement the interface will no longer compile – and in the case of dynamically loaded or linked plugins, will either fail to load or link, or crash at runtime. There are two basic approaches for dealing with this problem:

1. a new interface may be developed with additional functionality, which might inherit from the old interface
2. a software versioning policy such as semantic versioning 2.0 may be communicated to interface implementors, to allow forward-incompatible, or even backward-incompatible, changes in future "major" versions of the platform

Both of these approaches have been used in the Java platform.