Programming to an interface or other abstract types

Question

In a SO question on interface programming a commenter says -

Most answers to this question have the common misconception that "programming to an interface" means use the interface language construct; which is totally wrong! This is the first answer I've seen that correctly illustrates that "programming to an interface" means: don't unnecessarily bind your 'client code' to concrete/specific subclass implementations because if you later decide to change it use a different implementation, you have a lot more work undoing all the unnecessary bindings. I.e. program to/bind to things without implementation details. E.g. Abstract base classes.;)

Can some please expand on this point, preferably in relation to c#.

He's really just pointing out that other keywords (besides 'interface') provide polymorphism. Its kind of a strawman that he's arguing against but w/e — heisenberg, Jan 28 '13 at 15:51
When you declare an interface in c#, you specify **what** a class will do, rather than **how** it will do it. By separating the how and the what, you make it a lot easier to replace the **how** later, whilst making sure that **what** your new module does stays the same. — paul, Jan 28 '13 at 15:54

D Stanley · Accepted Answer · 2013-01-28T16:09:19.560

My interpretation is that the answer is just expanding the notion of "interface" to mean binding to any set of properties and methods whether a "pure" interface (i.e. an interface in C#) or binding to a particular implementation. The answer's point was that you could consider a class an "interface" by itself, and so you should program to the lowest base class that is necessary for your usage (a generic List contract versus a more specific ArrayList contract is that example).

You see this a lot in System.IO classes that bind to an abstract TextReader class versus an (non-existent) ITextReader interface.

Tigran · Answer 2 · 2013-01-28T16:02:02.257

Example:

If you have a method that makes an "animal" run in your mobile game, you can define a single IAnimal interface, and for every animal define its own run chinematics.

public interface IAnimal {
   Run(); 
}

public Dog : IAnimal{
   public void Run() {
       //DOG RUN CHINEMATICS
   }
}

public Elephant: IAnimal{
   public void Run() {
       //ELEPHANT RUN CHINEMATICS
   }
}

So you hide concrete implementation behind the IAnimal abstraction (its usually called contract for interfaces).

So during your physics engine run you can simply define one method:

public void RunAnimal(IAnimal animal) {
    animal.Run(); 
}

and call it like:

RunAnimal(new Dog());         //WILL CALL DOG CONCRETE METHOD
RunAnimal(new Elephant());    //WILL CALL ELEPHANT CONCRETE METHOD

So for RunAnimal method the concrete impementation detail of animal is hidden behind IAnimal "wall".

EDIT

So the answer to the question "why is programming to an interface not simply using the interface construct?" is:

An interface is and instrument which you can use to construct interface or contract based architecture. The same can be achieved simply by using abstract base class, or simple base class with virtual methods. So "programming to interface": is programming by having in mind to hide a concrete implementation detail from the consumer code (as much as it possible), to ensure maximum maintanibility, flexibility and scallability of your program. Use interface, abstract class, base class, whatever you want.

So how does this contrast with just having a base (abstract) `Animal` class? — Matt Burland, Jan 28 '13 at 15:50
@It does not *contrast* (in the meaning of that word in english), but just have different attributes. One of the most important one is possibility of multiple inheritance in case of interfaces. — Tigran, Jan 28 '13 at 15:53
This doesn't really answer the question. The question is not *"what is programming to an interface?"*, but "*why is programming to an interface not simply using the **interface** construct?*" — Alexander R, Jan 28 '13 at 15:55
@AlexanderR: Right, hence my comment on using an abstract base class, which can achieve the same aim, but with the restriction that you can do multiple inheritance (unless you have some horribly convoluted inheritance tree - an even then it's not quite the same thing). (BTW: I didn't downvote) — Matt Burland, Jan 28 '13 at 15:58

score 2 · Answer 3 · edited Nov 26 '13 at 21:06

2

With interface you have just signature of methods
With abstract class you can set common behavior of your child class, so write common code
multiple inheritance is impossible for C# so

you can implement multiple interfaces and not inherit multiple abstract class

When you create distribued component such as WCF Remoting etc.., you implement interface in order to communicate with your client.
You can use interface in order to tag a class

edited Nov 26 '13 at 21:06

Donato Szilagyi

4,279
4
36
53

answered Jan 28 '13 at 15:53

Aghilas Yakoub

28,516
5
46
51

Sums up the few differences. Whether you use an interface or an abstract base class, you're still programming to an abstraction in that you're not coupled to any specific concrete implementation. The decision to use either one, or both, depends on the situation. – JosephHirn Jan 28 '13 at 16:01
Thank's Ginosaji for complement, it depend of your case – Aghilas Yakoub Jan 28 '13 at 16:04

Programming to an interface or other abstract types

3 Answers3