What do you mean by "programming to interface" and "programming to implementation"?

Question

In the Head First Design Patterns book, the author often says that one should program to interface rather than implementation?

What does that mean?

Answer 1

Let's illustrate it with the following code:

namespace ExperimentConsoleApp
{
    class Program
    {
        static void Main()
        {
            ILogger loggerA = new DatabaseLogger();

            ILogger loggerB = new FileLogger();

            loggerA.Log("My message");
            loggerB.Log("My message");
        }
    }

    public interface ILogger
    {
        void Log(string message);
    }

    public class DatabaseLogger : ILogger
    {
        public void Log(string message)
        {
            // Log to database
        }
    }

    public class FileLogger : ILogger
    {
        public void Log(string message)
        {
            // Log to File
        }
    }

}

Suppose you are the Logger developer and the application developer needs a Logger from you. You give the Application developer your ILogger interface and you say to him he can use but he doesn't have to worry about the implementation details.

After that you start developing a FileLogger and Databaselogger and you make sure they follow the interface that you gave to the Application developer.

The Application developer is now developing against an interface, not an implementation. He doesn't know or care how the class is implemented. He only knows the interface. This promotes less coupling in code and it gives you the ability to (trough configuration files for example) easily switch to another implementation.

Answer 2

Worry more about what a class does rather than how it does it. The latter should be an implementation detail, encapsulated away from clients of your class.

If you start with an interface, you're free to inject in a new implementation later without affecting clients. They only use references of the interface type.

Answer 3

It means that when working with a class, you should only program against the public interface and not make assumptions about how it was implemented, as it may change.

Normally this translates to using interfaces/abstract classes as variable types instead of concrete ones, allowing one to swap implementations if needed.

In the .NET world one example is the use of the IEnumerable/IEnumerator interfaces - these allow you to iterate over a collection without worrying how the collection was implemented.

Answer 4

It is all about coupling. Low coupling is a very important property* of software architecture. The less you need to know about your dependency the better.

Coupling can be measured by the number of assumptions you have to make in order to interact/use your dependency (paraphrasing M Fowler here).

So when using more generic types we are more loosely coupled. We are for example de-coupled from a particular implementation strategy of a collection: linked list, double linked list, arrays, trees, etc. Or from the classic OO school: "what exact shape it is: rectangle, circle, triangle", when we just want to dependent on a shape (in old school OO we apply polymorphism here)