Question

It is often recommended to “program to an interface, not an implementation”. It is useful to promote separation of concerns, and helps with unit testing. However, I was thinking about API programming.

Let’s say I wrote an API and that API used a lot of “programming to interfaces”. Let’s also say that the API was insanely popular and used by many external clients. If one of the interfaces in the API had to change, that would require apps using the API to be recompiled.

My question is, how is such an issue avoided (or the impact of such changes reduced), or is it unavoidable? I am not an API programer and would like to know the best practice here. It seems to me that changing an interface that has existed for a long time and is widely used is a bad idea.

Answer 1

Published interfaces should never change. In the case that you have to augment functionality, just add a new interface.

To quote from MSDN:

When you create an interface, you are
creating a definition that can never
change after the interface definition
has been released. This interface
invariance is an important principle
of component design, because it
protects existing systems that have
been written to use the interface.

When an interface is clearly in need
of enhancement, a new interface should
be created. This interface might be
named by appending a “2” onto the
original interface name, to show its
relationship to the existing
interface.