Explaining interfaces to beginning programmers?

Question

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?

Thanks

Answer 1

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.

Answer 2

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.

Answer 3

interfaces being like a contract between programmers.

That's wrong.

An interface isn't "like" a contract.

It is a contract.

Answer 4

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.

Answer 5

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.

Answer 6

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

Answer 7

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.

Answer 8

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.

Answer 9

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?

Answer 10

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.

Answer 11

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

Answer 12

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. :)

Answer 13

First of all they have to know how interfaces work. I mean not only that they should know how to write an interface and implement it. They also should be able to understand that they can write codes(methods or classes) that are only reliant on an interface, so as long as any object supports that interface those pieces of code will work on that object. They should be aware of consuming interfaces.

You could not ask them to use interfaces in general, but instead you should explain to them when(in which scenarios) an interface is required. I mean they need to get more familiar with design patterns and more importantly the object oriented principles. For example they need to know the importance of 'seperation of concerns' and its benefits to team and product, once they know why they should think about seperation of concerns and other principles, they will have a passion to know about design patterns as design patterns are there to support those principles or they may (re)invent patterns. In other words, unless they are concerned about software engineering principle they will not be able to employ interfaces correctly, so explain those principles and patterns as reasons for why they should interfaces.

Answer 14

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.

Answer 15

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).