Inheritance always seemed easy in the OO books but in practice it can be a real pain. The same code using interfaces may also be just as much a pain in the long run. I have yet to run into any large unwieldy interface structures, but the more I use them the more I can see it happening.

An interface can be annoying when you feel the urge to add static methods – sometimes I use abstract classes only for this reason.

There may be parts of the contract that you cannot specify or check well enough in an interface that makes you rather use a concrete class. For example, the algebraic type Option with implementations Some and None – it is useful to be able to guarantee that Some and None are the only implementations.

The mantra “code to the interface” is so often misunderstood that it is dangerous. It is badly in need of being publicly branded as an anti-pattern.

An example of this misunderstanding is ak’s comment above about requiring interfaces for mocking. Most Java mock object libraries support mocking of classes as well as interfaces (though you may need to enable this explicitly). This is due to the magic of libraries such as CGLIB.

If it is likely that only one implementation of a class is needed then skip the interface and create the class or maybe an abstract base class. When to create interfaces depends on how the API is going to be used and how long it is going to be in service and the likelihood that it will have multiple and concurrent implementations.

For more info on creating useable API’s I recommend a talk given by Josh Bloch at Google. Search for “How To Design A Good API and Why it Matters”.

Another overloaded term causing confusion.

It’s a good idea to have “Program to an interface, not an implementation” in the back of your head, but, as you state, that does not directly translate into creating an interface between every component of your system. When you talk about making changes in two places, your initial design was in violation of the open-closed principle. I think of the explicit interface of C++ or Java as an API.

It’s all about managing dependencies between your code by thinking about polymorphism.
The idea is that the interaction of your classes should be defined by an implicit interface, and when you are designing, you’re fitting those pieces together. When you go to code, it is then that you actually wire up, solder, plug in those interactions.

Here’s what Erich Gamma (one of the GoF authors) says about it in an interview:

Program to an interface, not an implementation

Bill Venners: In the introduction of the GoF book, you mention two principles of reusable object-oriented design. The first principle is: “Program to an interface, not an implementation.” What’s that really mean, and why do it?

Erich Gamma: 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 development tools 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.

You can find the rest of the interview here: http://www.artima.com/lejava/articles/designprinciples.html

However, if you find that your class is evolving beyond the original purpose, then it’s time to create a new class and/or interface (extending your previous if desired).

I have found interfaces to be and advantage while mocking unit test cases. Also while working with inversion of control (I use castle), interfaces provide a great deal of flexibility event when the code is internal and not expected to have multiple implementations.

Refactoring tools included or added to you favorite tool allow the addition/modification of methods and properties to be relatively painless. The little extra effort pays up the flexibilities in unit testing, IOC and preliminary design.

Much of the design patterns literature talks about programming to an interface. This stems from the the archetypal book on the subject: ‘The Design Patterns Elements of Reusable Object-Oriented Software’.

The authors were very careful to define the term interface, referring to the [implicit] interface of an object or number of objects. Unfortunately it’s still interpreted as referring to the [explicit] interface construct as exhibited by languages like C# and Java.

In this book was written by Smalltalk programmers and the examples appeared either in Smalltalk and or C++. Importantly, neither of these languages posses explicit interfaces.

In Smalltalk, messages are sent to objects at runtime. Given a message an object chooses how to respond; it may choose to ignore the message. Desecrate objects can respond differently to a message. The end result is that programs are written against implicit interfaces. There’s no need to explicitly define the interface of your objects .

Note: In Objective-C the interface confusion doesn’t exist as explicit interfaces are called Protocols. This is a much better name for explicit interfaces. If you have the opportunity I’d recommend learning this language as it embodies a lot of the ideas from Smalltalk, in a natively compiled language.