Explaining Interfaces to Students [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 6 years ago.

For a few years I was a teaching assistant for an introduction to programming module - Java for first year undergraduates.

Mostly it went well and we managed to get object-oriented programming across to the students quite well, but one thing that students rarely saw the point of was interfaces.

Pretty much any explanation we gave either came across as too contrived to be useful for learning, or too far removed from their position as beginners. The reaction we tended to get was "I... see," translated as "I don't understand and they don't sound useful".

Anyone here have a way of successfully teaching students about interfaces? I'm not a teaching assistant any more, but it's always nagged at me.

Answer 1

In this previous question there are some good scenarios that explain the whys behind the use of interfaces.

Stack Overflow Question

Answer 2

First, the students must grasp the concept of abstractions. When you (you == the students) see a teacher, you can describe him as a teacher... You can also describe him as an employe (of the school). And you can describe him as a person. You will be right the three times. Thoses are "titles" you can give him.

He is a teacher, a computer science teacher, in the same way a math teacher is a teacher. They are on the same level of abstraction. Now a teacher is an employee, in the same way a janitor is an employee. They are on the same level of abstraction. An employe is a person, in the same way an unemployed person is a person. They are on the same level of abstraction.

(Draw the whole thing on the board in a UML kinda way).

And that's the architecture that will describe (roughly) the position of a science teacher in society.

Now the levels of abstraction define what a common group of objects have in common : All the teachers teach to their students and create impossible exam questions to make sure they fail. All the school's employes work for the school.

In programming, an interface is a level of abstraction. It describes the actions that a group of objects can accomplish. Each object has a unique way of doing the action, but the type of action is the same.

Take a few music instruments for example : A piano, a guitar and a flute. What do they have in common ? A musician can play them. You can't ask a musician to blow in the 3 instruments but you can ask him to play them.

The architecture of the whole concept will be the following:

The Interface (what they have in common) is Instrument. Because they're all instruments : it's an abstraction they all have in common. What can they do in common ? Play. So you define an abstract method called Play.

Now you can't define how the "Instrument" will play because it depends on the type of instrument. Flute is a type of Instrument. So the class Flute implements Instrument. Now you must define what the musician will do when he plays that type of instrument. So you define the play method. This definition will override the definition of the Instrument. Do the same with the 2 others instruments.

Now if you have a list of instruments but don't know what type they are, you can still "ask" them to play. Each flute will be blown. Each guitar will be scratched. Each pianio will be ... huh... pianoted ? whatever !

But each object will know what to do to execute the action "Play". You don't know what kind of instrument they are, but since you know they are instruments, you ask them to play and they know how to do that.

Answer 3

Well I just explained interfaces to a work partner, she was learning java from progress and she really did not get all the OOP stuff at the beginning so I just explained everything from a non-software engineering point of view, my explanation for interfaces where something like this:

Suppose you want to hire a plumber to fix some things on your house, you don't know (and you don't care much) who you may end up hiring but you know what the plumber must be able to do. So, you define a set of tasks that anyone that claims to be a plumber must know how to do. Of course everybody might have its own way of carrying out each task, but in the end, the person you are hiring is a plumber because they know how to do each task. So, if you were to write this in java, the first thing to do would be to define an interface plumber like this:

public interface Plumber
{ //silly code here }

OK then, let's say that I know how to do each task you are requesting for and so I'm fully compliant with your requirements and so according to you I'm a plumber. So, today I decide to be your plumber and you decide to hire me (yay!), based on the last example, you can say that I'm a person that knows how to develop software and plumbing in a specific way, if I were to write code for me as a class I could write something like this:

public class Rick extends Person implements SoftwareDeveloper, Plumber

and later you could fix things in your house using me as your plumber:

Plumber thePlumber = rick;
thePlumber.fixLeak(myHouse.bathroom.leak) // =(

from this point on, the remaining OOP concepts were easy to explain.

Answer 4

If you are trying to explain it to beginners I would stick with the idea that interfaces can promote code reuse and modularity within the code:

For example lets say we are going to paint some objects:

public class Painter {
    private List<Paintable> paintableObjects;

    public Painter(){
       paintableObjects = new ArrayList<Paintable>();
    }

    public void paintAllObjects(){
        for(Paintable paintable : paintableObjects){
            paintable.paint();
        }
    }
}

public interface Paintable {
     public void paint();
}

Now you could explain to the students that without Paintable interface the Painter object would need to have methods to paint certain types of objects, like a method called paintFences() and paintRocks() and we would need to have a new Collection for each type of objects we want the painter to be able to paint.

But thankfully we have interfaces which make painting objects a breeze and how objects are painted is left entirely up to classes that implement the Paintable interface.

EDIT

Another benefit that I forgot to mention is that if you ever need to add new object to paint to your code base, all you need to do is create a new class that implements Paintable and the Painter class never has to change. In this sense the Painter class is never dependent upon the objects it is going to paint, it only needs to be able to paint them.

EDIT 2

James Raybould reminded me of a key use of interfaces I forgot to mention: Having an interface between your components, like the Paintable objects and Painter objects, allows you to more easily develop with other people. One developer can work on the Painter objects and another can work on the Paintable objects and all they have to do to function properly together is define a common interface beforehand that they will both use. I know when I've worked on projects with other people in college level projects its really helpful when you are trying to have everyone work on different parts of the project and still have all components come together nicely in the end.

Answer 5

In explaining interfaces and object oriented concepts in general to non-programmers, I always use the home entertainment system analogy.

The DVD player, TV, Cable Box, Remote Control are all objects that encapsulate complicated and sophisticated functionality. However, they have interfaces to each other and to the Humans that operate them that largely hide the lion share of that complexity.

The video in jack of a TV is an interface that is implemented by the DVD player and the cable box and a number of other types of devices.

I suspect it would be possible and perhaps an educational exercise for a student to describe their own home entertainment system entirely using Java code.

Answer 6

I always think of it as a mean to (verbally) communicate as little as possible because that (good communication) is the most difficult thing in software engineering. Same for Web Services and SOA. If you give somebody an interface and say "Please provide me this service." it is a very convenient way because you don't have to explain a lot, and the compiler will check if they did a proper job, instead of you! (I mean, not really but at least it'll ensure the methods are there).