Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

closed as off-topic by durron597, Snowman, jwenting, ratchet freak, gnat May 11 at 20:45

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions seeking career or education advice are off topic on Programmers. They are only meaningful to the asker and do not generate lasting value for the broader programming community. Furthermore, in most cases, any answer is going to be a subjective opinion that may not take into account all the nuances of a (your) particular circumstance." – Snowman, jwenting, ratchet freak, gnat
If this question can be reworded to fit the rules in the help center, please edit the 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

17 Answers 17

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

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
Could you give real world examples of "real world examples"? –  user1249 Mar 4 '11 at 9:55

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

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

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

I like to use the "promise" or "contract" analogy. Tell them that an interface is like a contract in that any concrete class that implements it MUST implement each of the methods as they are listed. In other words, by implementing an interface, a class is promising to implement all of its listed method signatures.

share|improve this answer

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

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

In the art of unit testing book, they reference interfaces as a method of abstraction really. The example involved being able to log messages without worrying if it was an EmailLogger implementing ILogger or FileBasedLogger or TextMessagingLogger. Write some code that logs using an ILogger. Maybe make them feel the pain by writing code that does not use an interface.

Basically what is confusing about interfaces to beginners is understanding why they are needed over plain old classes.

share|improve this answer

Interfaces are the basis of proper composition and shine in relationship with many design patterns (e.g. the Command pattern). As such, they are fundamental to sound OO design. Teach interfaces as the rule and class inheritance as the exception. Class inheritance (extends) is mostly unnecessary and widely misunderstood and leads to rigidity while promising flexibility. Interface implementation, on the other hand, leads to a more functional design and stimulates creativity.

A proper way to teach interfaces is to create a bit of undo functionality, with an interface 'Command', having two methods 'do' and 'undo' and a command stack.

Interfaces should be:

  • Coherent (the methods should have an obvious relationship, such as do() and undo(), fork() and join()),
  • Obvious to implement (the pre- and post-conditions of each method should be easy to understand, even though the implementation of the interface might be complex). This guarantees encapsulation and reuse,
  • Well named (generally the name should be an adjective, although exceptions can be made, such as the Command above).

Finally, interfaces generally define the façade of a more complex system, in order to insulate implementation changes in a future release from the users of this system.

share|improve this answer

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

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

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

It is useful at first to think of classes as an is-a relationship and interfaces as features not necessarily inherited. Example class Sheep extends Animal implements HasLegs

share|improve this answer

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

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

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.