Take the 2-minute tour ×

I've had discussions with other programmers on interfaces (C#). I tried to use the analogy of interfaces being like a contract between programmers. Meaning that when you design to an interface, you are designing to a "thought out plan".

This didn't fly. The other programmers (limited experience) couldn't get the concept. Or worse, refused to participate.

How do you explain to people like that there are reasons to use interfaces?


share|improve this question
Or worse, refused to participate. - that's a firin'. –  Jesse C. Slicer Mar 3 '11 at 19:26
You really can't explain it much better. You need to show them. –  ChaosPandion Mar 3 '11 at 19:27
I consider an interface to be more like an outlet, or a computer port. It's designed to accept a specific input, in a specific shape, and anyone wanting to use something that's designed to the interface only has to implement the interface. –  zzzzBov Mar 3 '11 at 20:24
For C++ devs, tell them it's a .h file that is not allowed to be changed. That's how it was explained to me when I learned Java, and it worked. As for the why of it, I like grefly's answer. –  Matthew Read Mar 3 '11 at 20:50
What level of OOP principals do they understand? If they don't get encapsulation, you may have to turn the knob on the Wayback Machine. –  JeffO Mar 3 '11 at 21:39
show 2 more comments

14 Answers

Essential C# 4.0, Mark Michaelis, Addison-Wesley Professional, 2010:

Implemented interfaces are like appliances with wall plugs. The wall plug is the interface that appliances support in order to receive AC power. An appliance can use that power in countless ways, but in order to plug into a wall socket, an appliance must supply a compatible wall plug. What the appliance does with the power corresponds to how an interface implementation varies from class to class. The specification that defines a wall plug is the contract that must be supported in order for an appliance to plug into the wall plug. Similarly, an interface defines a contract that a class must support in order to gain the capability that the interface provides." p.306, Beginner Topic.

share|improve this answer
Yes, wall plugs or USB ports or similar are a great example. I have used it before to successfully transmit the idea. –  R. Martinho Fernandes Mar 3 '11 at 22:53
In a similar vein, an interface is the set of behaviors specific to an object role (not necessarily a particular class). Eg, Actions an eater takes (intake, mash, swallow, digest, etc); Actions a sleeper takes (yawn, doze off, snore, restless leg, awake). –  JustinC Mar 5 '11 at 3:43
An old friend once described this as "If you can plug two things together, you're allowed to plug them together." At the time, he was railing against the trend towards using RJ-11 jacks as keyboard connectors. –  Ross Patterson Feb 22 '12 at 2:23
add comment

Give real world examples...

...and explore alternatives

Most of the time, if you don't take the time to listen to what they have to say, they won't want to listen to you at all.

share|improve this answer
+1 and try to come up with some really awful code that results from not using interfaces. Something really terrible. ...that will make them dry-heave, that will keep them up at night, that will make them fear the dark... ;) –  FrustratedWithFormsDesigner Mar 3 '11 at 19:33
@FrustratedWithFormsDesigner: exactly! Thanks for that great comment. "What's in it for me?" –  user2567 Mar 3 '11 at 19:41
Could you give real world examples of "real world examples"? –  user1249 Mar 4 '11 at 9:55
add comment

interfaces being like a contract between programmers.

That's wrong.

An interface isn't "like" a contract.

It is a contract.

share|improve this answer
Should be a comment. –  Matthew Read Mar 3 '11 at 20:50
@Matthew Read: I thought it was a better explanation than the one that was being used. You disagree? –  S.Lott Mar 3 '11 at 21:09
Not exactly (that's why no downvote), but I do think the question being asked is how to explain why such contracts are necessary. –  Matthew Read Mar 3 '11 at 21:18
It's not a contract, not really (in most languages), since it doesn't actually constrain the semantics. It's possibly better to use “protocol” (IIRC, Objective-C uses that exact word) as that's less wrong, but it's still not perfect as in the real world protocols still imply semantics (typically in relation to ordering of operations). “Interface” is best. Oh… –  Donal Fellows Feb 21 '12 at 22:45
add comment

I think interfaces will be best explained by a practical example:

Say you need a list. What are the properties of a list? Well, you can add items to it, remove items, check if an item is already in a list, and so on. These are all properties you would expect of a list, so why not define functions or methods to provide this functionality from any list? E.g. (in some sort of pseudo-code):

bool addItem(item);
bool removeItem(item);
bool contains(item);
void clear();

and so on ...

This is the interface. Now, when you're programming an application that uses a list, instead of defining that you use this particular list you instead define that you're using a list:

Instead of

ArrayList items;

you do

List items;

Why would you want to do this? Why not just settle with any list and be done with it? Well, no all lists are implemented equally. In some lists you can maybe add items very fast, but it takes a long time to remove an item, or maybe some lists are very space-efficient but costs in execution, and so on.

If you had define to use a particular list and decide that you want to use another list, you would need to replace all occurrences of AParticularList with AnotherParticularList. If, instead, you had defined them as List, you would only need to change where you specify which list to use (i.e. instantiations).

Now, some astute colleague of yours maybe wonder "Why don't we just define a list as class and let all other lists inherit from it?" Sure, you could do that, but then you would only be able to define what functions or methods all lists should have, and not any actual functionality which all lists should inherit as each list will be implemented differently. Hence, you would have an abstract class with methods defined, but no functionality, and all subclasses would need to implement those methods. This is precisely what an interface is.

EDIT: Another important point about using interfaces is when you design a set of library functions which others will use that require them to provide a particular object. The object is required to implement certain functions or methods which will be called within the library functions. If you had provided an abstract class for your API users to inherit, then it becomes difficult if the provided object also needs to inherit from another class (if the language doesn't allow multiple inheritance). If, instead, you only required the object to implement an interface then it's no longer a problem, since a class can always (at least in the languages I've heard of) implement multiple interfaces.

share|improve this answer
add comment

Have them draw up a small, simple paper contract (just a line or two should do it) that guarantees them something material - have them use a monetary value, that will get their attention. Then you sign it, saying you agree to provide what is on the contract.

Then have them come to collect, explaining that (in the money situation) you are giving them exactly what they asked for. They aren't asking where it came from or how you got it, and they don't really care, as long as they get the money.

Another example could be a contract for a car. Ask them to define what they want in the car, and give them only what they have asked for. Forgot to ask for a steering wheel? Well, you don't get one then...

Same thing with Interfaces.

share|improve this answer
add comment

Using the House method tends to work quite well:

An interface is a basic description of a class (or blueprint for an object). So an interface for a house would indicate that you in the house you must have a roof, walls, foundation, etc. This is useful because then you can define and implement any objects or functionality that may be needed for more complex objects when the basic ideas are the same... for example a door object needs to be able to open and close and has certain properties that would always be the same for each door. Why create the functionality multiple times? Just create

share|improve this answer
add comment

Maybe their real question is "Why bother with interfaces? We're getting along fine with just classes."

Interfaces serve precisely one purpose: to allow one class to invoke methods in another class without a direct dependency. So to explain interfaces, you are going to have to find an example where a direct dependency is intolerable, and then show how using an interface solves that problem. It should be simple enough in C#. Surely they are already using interfaces to work with library classes.

share|improve this answer
add comment

Compare the Interface to the user Interface of an application with human users.

If the GUI is locked down and doesn't change you can change how the application does things behind it and the users will not know anything has changed. The application can go from a using access on the local machine to using some database in the cloud and the user will not have to, in theory, change what they do or how they do it.

The class interface is the same thing except for developers and the classes they write are the users. A developer can take the interface passed to them and use it just like before even if that interface is now a completely different concrete object.

Another example I have used is the mouse as Interface. If everybody has ball type mice you cold go to each desk and replace them with optical mice and everybody could still work. Then you could go and replace the optical with a laser wireless mouse and they could still work like before. The three are completely different OBJECTS with very different ways of how they are implemented but the INTERFACE the human uses is the same.

share|improve this answer
add comment

This "real world example" has happened to me many times:

  1. I first started to use ArrayList to implement something in a class and expose the list to outsiders.

  2. Then I notice that it was probably a better idea to use a HashMap instead, for one reason or another.

If I specified the return value as a List first and HashMap later, all users of that class needs to be rewritten.

If I specified the return value as a Collection (that is, the interface that is implemented by both List and Maps) all users (such as other objects) that had to use this class wouldn't need to rewrite their code.

That's why it's a good idea to program to interfaces and not concrete implementations.

More examples can be found here: http://stackoverflow.com/questions/383947/what-does-it-mean-to-program-to-an-interface

share|improve this answer
add comment

During my time as a teacher I allways used a little graphic to tell them, what is a Interface: a stencil.

I would never start with difficult explainations. STart easy going. Your people have to understand first, that a class which uses a interface has to implement all its members. And second that all classes, inherits from the interface, can be used like the interface. :)

share|improve this answer
add comment

It is a way to declare that "this class has/does x", similar to marking methods and properties piblic, but applicable to multiple methods/properies, and can be shared with non-related classes (for example IComparable and IEnumerable).

The benefit of using an interface is that the consumer of the interface does not need to care about the type of the object. You might think of it as duck typing done safely.

share|improve this answer
add comment

An interface is everything that is visible/usable from the outside of an entity. The interface of a class would be all the public methods, properties and fields.

Implementing an interface on a class means providing a defined set of public methods, properties and fields. Different classes implementing that interface can then be dealt with uniformly.

share|improve this answer
add comment

USB protocol

Use the example of the USB protocol, which I am certain they must have heard of.

A properly designed interface allows for plugging in any USB-device so that the hardware level stuff is taking care of. Ask them to consider with there is gazillions of cheap USB-devices and not for instance PS/2-based or SCSI-based TV-tuners?

share|improve this answer
add comment

I think the problem here is your own perspective on objects. Classically, objects are defined through classes and thus types and their hierarchies are defined through classes.

This is the problem. An interface is the description/definition of an abstraction. And types actually are abstractions.

A classical example for explaining OOP and type hierarchy is:

class Car {
      //...some properties
class Bus extends Car {
      //...some more properties

This sooner or later yields violation of the Liskov substitution principle and has a lot of other problems.

Actually, Car should be defined as an interface, and 2CV (or whatever makes you happy), is an implementor. The 2CV for example also happens to implement ConstructionKit (appearently you can quite easily dis- and reassemble it with a single wrench).

share|improve this answer
add comment

Your Answer


