Interfaces before Inheritance?
One of the great things about finding colleagues is that they give you new ideas. Case in point: Eugene Wu hit me with a really interesting one as we drove to work the other morning. In Java, he teaches interfaces before teaching inheritance.
Now I’ve always thought of interfaces as a language feature designed to solve issues related to multiple inheritance by creating the concept of a special sort of class — an interface — containing only what Java calls “abstract” methods, the things that C++ calls “pure virtual” functions. Because of that perspective, I had never even considered teaching interfaces before teaching inheritance. In my mind, the tension between method call resolution in multiple inheritance versus the benefits of polymorphism motivates the interface as a construct.
But look at the advantages to ignoring that: If we don’t need to really know about method call resolution or method overriding yet, the interface can be presented simply as a contract that an implementing class agrees to meet, and a mechanism for creating new reference data types. This lets us introduce the concept and benefits of polymorphism before we even talk about inheritance! Then when it’s finally time to create a subclass, we already have the basic idea of overriding (providing a new method body for a given signature) and it’s pretty nice that it’s optional.
I can see this flow reducing the cognitive load by pulling apart some of the concepts so students can learn them separately. I’m strongly considering doing this in my AP class this year. It will be a bit tricky since the book I use, Head First Java, introduces the topics in the opposite (traditional) order. But maybe it’s time to break out beyond the structure of that book.