Program to an interface, not an implementation

In the introduction of the GoF book, the GoF mention an important principle of reusable object-oriented design. The principle is: "Program to an interface, not an implementation". The basic reason behind it is to achieve the flexibility in choosing different implementations at run-time as many times via the interface. This is achieved because of the polymorphism feature of the OO languages. The power of interfaces is best understood in design patterns. Most of the design patterns such as Strategy, State, Command, Abstract Factory Method are actually the above principle in practice. Now how do we try to abide by the principle? The best way is to strive for having method signatures with more generic, interface or parent class type method parameters and return types. Also it is advisable to declare class member variables to be of a more generic, interface or parent class type rather than a concrete implementation. The advantages of using interfaces (pure interfaces and/or abstract base classes) are as follows:

• It is always painless to depend on interfaces. Client classes depending on the interfaces remain unaware of the concrete classes they use indirectly via the interface , as long as the concrete classes adhere to the interface that clients expect. This makes the clients more resilient to changes in implementation details.
• The above aspect makes unit testing also very easy. In order to test a client class that depends on a complex computation exposed by an interface, we can create a mock stub object that implements the interface to replace the complex computation object.
• Depending on interfaces has benefits even beyond just programming. The more we depend on concrete classes, the more complex dependency structures become, as a result our build scripts and build processes also tend to be more unwieldy.

Erich Gamma, one of the GoF, explains in an interview: "This principle is really about dependency relationships which have to be carefully managed in a large app. It's easy to add a dependency on a class. It's almost too easy; just add an import statement and modern Java IDEs like Eclipse even write this statement for you.Interestingly the inverse isn't that easy and getting rid of an unwanted dependency can be real refactoring work or even worse, block you from reusing the code in another context. For this reason you have to develop with open eyes when it comes to introducing dependencies. This principle tells us that depending on an interface is often beneficial."