8

Ideally, interfaces come first. Before Classes. Interfaces define concepts. Classes implement those concepts. Don't think of them as an add-on to OO programming. Think of them as the essence. In fact, if you present a pre built class to students, my guess is that you already, probably informally, give the interface first. Here is a class with public ...


6

This answer draws on Java examples. I start the interface discussion with a mechanical SATA hard drive in my hand. I discuss the interface called SATA and its universality across devices. I expand this with some digital images of SATA on an optical disc drive as well as a solid state hard drive. Some discussion follows regarding the variety of brands and ...


5

I believe that using the term "contract" is hurting more than helping. Most students in that age-range have no personal experience with contracts, so the term is too abstract or remote. Secondly, using contract to "define" the rules for using an interface is likely to lead to a circular definition when you define what a contract is. To increase comprehension ...


5

A few things jump out from the official Java documentation: As far as an example goes, the idea of a Remote as an interface works really well based on this explanation. Methods form the object's interface with the outside world; the buttons on the front of your television set, for example, are the interface between you and the electrical wiring on ...


2

I really enjoy the answer to this question provided on StackOverflow and use it as a basic introduction/discussion point in my CS2 course: Consider the following situation: You are in the middle of a large, empty room, when a zombie suddenly attacks you. You have no weapon. Luckily, a fellow living human is standing in the ...


2

I have a bit of a quibble here. The only thing enforced by Java when implementing an interface is the structure of the class implementing it. The intent of the interface programmer isn't enforceable. Good names will help express the intent, but not enforce it. Good javadoc comments will convey more of the intent, but again it isn't enforceable. Absent some ...


2

I'd say that it can fit very well between the Inheritance and the Polymorphism. Interfaces are a way of promising that any implementing class supports the interface's functionality. for example, given an interface Movable: public interface Movable { public void move(); } one knows that anything that for any object instance of a class which ...


2

An interface "isn't" a contract. But it embodies a contract. Implicitly if not explicitly. A simple example is when you go to Kinko's (FedEx), and you click on the end of the opening interface that you agree with the terms of use. In turn, Kinko's agrees to provide you with a bunch of computer services, express or implied, for the money you are paying them....


2

One huge advantage to using Greenfoot is the visualization and interactive nature of the application. Using and demonstrating interfaces will take some work though. Anything that gets added to the world will be displayed and interacted with as it's actual type via the context menu. This can be confusing as students will be able to execute (via the context ...


2

Yes, Greenfoot certainly has interfaces. I doubt that they would take them out. The people who built greenfoot are likely as appalled as I am about the College Board action on interfaces. But there is no UI element that specifically adds a new interface to a project. But they may not appear in the same place that most classes do in the sidebar. Look at the ...


1

My laundry list: We write sample programs using components from a library (say JavaFx, or SFML) We don't care (much) about the internals of objects, as long as they work, but about their programming interface = what we can do with them. Abstraction. Anyway, we're going to build new objects. Some explanations about classes/methods/fields. Encapsulation. ...


1

Interfaces should be taught right after, or during the section on APIs, because they are simply a promise to implement a certain Application Programming Interface. It's why they are called interfaces in the first place. They are also more general than inheritance, which makes them a much better example as a polymorphic data type. With this in mind, I propose ...


1

Java (and most other languages) interfaces are not contracts. The contract on Eat is: I take no data I return no data you can call me under any situation I will not crash/throw (most languages don't even have this) I will do what ever seem like a good idea to me I.E. there is no contract. They don't see it because it is not there. Without pre and post ...


Only top voted, non community-wiki answers of a minimum length are eligible