job.answiz.com
  • 4
Votes
name
name Punditsdkoslkdosdkoskdo

What is “programming to an interface”

I have come across the term "programming to an interface instead of an implementation" a lot, and I think I kind of understand what it means. But I want to make sure I understand it's benefits and it's possible implementations.

"Programming to an interface" means, that when possible, one should refer to a more abstract level of a class (an interface, abstract class, or sometimes a superclass of some sort), instead of refering to a concrete implementation.

A common example in Java, is to use:

List myList = new ArrayList(); instead of ArrayList myList = new ArrayList(); .

I have two questions regarding this:

  1. I want to make sure I understand the main benefits of this approach. I think the benefits are mostly flexibility. Declaring an object as a more high-level reference, rather than a concrete implementation, allows for more flexibility and maintainablity throughout the development cycle and throughout the code. Is this correct? Is flexibility the main benefit?

  2. Are there more ways of 'programming to an interface'? Or is "declaring a variable as an interface rather than a concrete implementation" the the only implementation of this concept?

I'm not talking about the Java construct Interface. I'm talking about the OO principle "programming to an interface, not an implementation". In this principle, the world "interface" refers to any "supertype" of a class - an interface, an abstract class, or a simple superclass which is more abstract and less concrete than it's more concrete subclasses.

To quote from the Gang of Four’s design patterns book, using interfaces means the following:

 

  1. Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that clients expect.
  2. Clients remain unaware of the classes that implement these objects. Clients only know about the abstract class(es) defining the interface.

 

Great! Super awesome. But what does this actually do for me?

You’ll Have Code That’s Easier to Modify

Interfaces make your code less brittle. If implementations change, your code will still work—as long as the interface doesn’t change.

Let’s consider a very simple C# example. Suppose I need to have a collection of objects. Right now I don’t care too much about implementation. A collection is a collection. So I’m going to use a List<T>.

However, I don’t want to commit to using a List<T> everywhere, so I use the ICollection interface instead, like this:

1

2

3

4

5

6

ICollection<String> MyCollection = new List<String>();

 

MyCollection.Add("hi");

MyCollection.Add("there");

 

//...


A few months down the line, I find that a HashSet will give me better performance. Fortunately, since I used the ICollection interface, I only have to change my code in one place. That’s where I instantiated that collection:

 

1

2

3

4

5

6

ICollection<String> MyCollection = new HashSet<String>();

 

MyCollection.Add("hi");

MyCollection.Add("there");

 

//more stuff


Every method I’ve called on MyCollection exists on both List and HashSet, so I don’t have to worry about breaking anything.

 

But designing around implementation results in brittle code. It has to change in many fun and unexpected ways any time some downstream implementation changes. Or when you need to switch to a different implementation altogether.

  • 0
Reply Report

There are perhaps two usages of the word interface being used here. The interface you are mainly referring to in your question is a Java Interface. That is specifically a Java concept, more generally it's a programming language interface.

I would say that programming to an interface is a broader concept. The now popular REST APIs that are available for many websites are another example of the broader concept of programming to an interface at a higher level. By creating a layer in between your code's inner workings and the outside world (people on the internet, other programs, even other parts of the same program) you can change anything inside your code as long as you don't change what the outside world is expecting, where that is defined by an interface, or contract that you intend to honour.

That does then provide you the flexibility to refactor your internal code while not having to tell all the other things that depend on its interface.

It also means that your code should be more stable. By sticking to the interface then you shouldn't break other people's code. When you really have to change the interface then you can release a new major version (1.a.b.c to 2.x.y.z ) of the API which signals that there are breaking changes in the interface of the new version.

As @Doval points out in the comments on this answer there is also locality of errors. These I think all boil down to encapsulation. Just as you would use it for objects in an Object Oriented design, so this concept is also useful at a higher level.

  • 0
Reply Report

"Programming to an interface" means, that when possible, one should refer to a more abstract level of a class (an interface, abstract class, or sometimes a superclass of some sort), instead of refering to a concrete implementation.

This is not correct. Or at least, it is not entirely correct.

The more important point comes from a program design perspective. Here, "programming to an interface" means focusing your design on what the code is doing, not how it does it. This is a vital distinction that pushes your design towards correctness and flexibility.

The main idea is that domains change far slower than software does. Say you have software to keep track of your grocery list. In the 80's, this software would work against a command line and some flat files on floppy disk. Then you got a UI. Then you maybe put the list in the database. Later on it maybe moved to the cloud or mobile phones or facebook integration.

If you designed your code specifically around the implementation (floppy disks and command lines) you would be ill-prepared for changes. If you designed your code around the interface (manipulating a grocery list) then the implementation is free to change.

  • 3
Reply Report