Separation of interface from implementation

The Separated Interface pattern prescribes to define an interface into a package P but implement it in another one Q. The goal of the pattern is one of the most noble in software engineering: breaking dependencies.

In our example, Q depends now on P, but P does not depend on Q. The dependency is now backwards with respect to the classic solution of keeping interface and implementation together.

In fact, this pattern is commonly used to implement Dependency Inversion: if the interface was kept with its implementation, P would have dependended on Q. There are obviously various techniques to realize then instantiation and lifecycle management (such as Dependency Injection or a Service Locator).

When using this pattern, higher-level components do not depend anymore on lower-level ones, but only on their own abstractions, contained in them. Different implementations for the lower-level components can be used.

This approach can be taken further by defining an intermediate packages for the interfaces: P depends on A (Abstraction) by composition, while Q depends on A by implementation or subclassing. Also according to Fowler, this variation comes handy when there is more than one client package (homegeneous to P).

Benefits

Separating interface from implementation is desirable for achieving flexible, extensible, portable and modular software. If client code depends only on the interface to an object and not on the object’s implementation, a different implementation can be substituted and the client code continues to work, without change or recompilation. Furthermore, the client code continues to work on objects supporting an expanded interface.