Describing what an Interface is for?

Question

How would you describe the purpose of an Interface to a student-class that understand basic OOP design?

Answer 1

I prefer the term "contract" to interface, it defines a "contract" that any implementor must abide by.

Answer 2

First of all I would say that we have a Team and Programming Manager is going to inforce you to implement some certain functionality for example in Java or C#. They design the interface and "you" by implementing that interface garanteee that your class has the same functionality. And afterwards I would talk to them some advantage that interface might gives

Answer 3

An interface is what the implementor promises to do. It's like the list of features he supports.

Answer 4

quote from http://java.sun.com/docs/books/tutorial/java/concepts/interface.html

Implementing an interface allows a class to become more formal about the behavior it promises to provide. Interfaces form a contract between the class and the outside world, and this contract is enforced at build time by the compiler. If your class claims to implement an interface, all methods defined by that interface must appear in its source code before the class will successfully compile.

Answer 5

Like already mentioned a contract is a good word, but it also lets you have different implementations of the same thing (jdbc drivers for example..). Another good thing is using interfaces increases the code testability, but that might be harder to explain..

Answer 6

In interface is part of a contract. It specifies which member the implementing class must provide. However, it does not specify what these members have to do.

That's why an interface definition always needs an additional document (or comment) to explain what each member must "do".

For example, if the interface includes a method, Add with two integer parameters and one integer result, you need to provide the information that the result has to be the sum of both parameters. (And this is a trivial example, but misunderstandings can be very troublesome at this point).

Answer 7

Go with peters link and info, and find yourself some examples. Examples are an important didactic tool. (one should beat the man page writers with some, for instance)

Addit: There are some very simple but descriptive ones like, IComparable, ISerializable, ...

Answer 8

As everyone else has said an interface is a contract. Classes implementing an interface promise to provide the methods specified. But in my own studies I really wanted to know why that is important, why not just use inheritance instead?

I don't have a lot of experience with OOP but I've written my thoughts below. I'm sure other more experienced OOP programmers can add more to this (or correct me if I've made a mistake).

In languages that don't support multiple inheritance, otherwise unrelated classes can share functionality by implementing the same interface.

I find it easier to understand the difference by looking at inheritance and interfaces in terms of relationships. A class inheriting from a base class has an is-a relationship with that class, whereas a class implementing an interface has an implements relationship with that interface.

To borrow an example from Programming C# 4th Edition a car is-a vehicle and a house is-a building, yet both classes might implement the CanBeBoughtWithABigLoan capability.

Answer 9

As a n00b long ago, the term "contract" never did really make any sense to me. I pondered it for a long time and still couldn't come to terms with it. It did not help me understand interfaces at all...not in the least.

So, when I teach others I put it in terms of "characteristics" instead.

So an interface describes characteristics of a type. And a specific type can have multiple sets of characteristics. However, those characteristics must be specifically defined (implemented) by the developer when (s)he decides a type must have those characteristics.

Then, to take it further, I use things like animals while defining sample interfaces instead of typical realistic software solutions. That makes it easier for the student to visualize the need for the interface. On occasion, I use buildings/houses as examples as well.

On occasion, depending on the audience, I'll also use plugs & receptacles from Lowe's or Home Depot to give the example. IE: Have several plugs on the table. They all have different characteristics. But there are two observations:

1. The plugs aren't implemented. They have no cords hooked up to an encapsulated power source or "codebase" that defines what the interface will provide when it's running.
2. I only use one type of receptacle that'll fit only one of the plugs in the samples. the other's "characteristics" won't allow the receptacle to use the interface because the receptacle doesn't "implement" the interface characteristics.

I hope this helps.