Java confusion: extends vs implements

[gusl]

Given classes A and B,

A extends B
means that instances of A can invoke methods implemented in B.

A implements B
means that A implements the interfaces in B. The methods are implemented in A.

In this sense, "extends" and "implements" are opposites.

But I often think of them as being the same, because with the class names normally used, both of them can be read as "ISA". This is confusing.

I think the solution is to consciously distinguish "is a subtype of" from "is an implementation of".

---

Multiple inheritance is a bit tricky. I don't understand how all these things fit in, but from here I learned that:

* You need to create a new class Child, to be the result of the mix between Parent (first parent) and Other (second parent).
* Child extends Parent and implements 2 interfaces, MProvides and MRequires.
* There is a class called Mixin, used for the purpose of communicating with Other, which implements MProvides, and whose constructor requires an instance of MRequires. This instance simulates a parent-class for Mixin.
* The Child's constructor instantiates a Mixin, passing itself "this" as an argument. For each method func(...) that you inherit from Other, you need to write a implement a method mixin.func(...)

I don't yet understand whether this last annoyance is circumvented with "General Multiple Inheritance".

Comments

[ekorber.livejournal.com]

This was a topic covered in the class I taught this summer. My notes are here if you're interested.

[gustavolacerda.livejournal.com]

Whoa, we totally need to live together now!

Thanks for the notes.

[gustavolacerda.livejournal.com]

Given:

public class A extends B {
   ...
}

public class B {
   ...
}

how would you refactor A to use "implements" instead of "extends"?

[ekorber.livejournal.com]

Change public class B to public interface B. Cut-and-paste any code in method bodies in B to the corresponding method bodies in A.

[gustavolacerda.livejournal.com]

Ok. But then you've lost the modularity that inheritance gives you...

He is implying that in the hardcore professional software engineer world, everyone gives up modularity.

[ekorber.livejournal.com]

Sorry, if there was a <sarcasm> tag, I would have used it. Silly text-based communication...

[gustavolacerda.livejournal.com]

it is kinda funny how a < sarcasm > tag wouldn't work.

[shaktool.livejournal.com]

The "extends" vs "implements" thing is pretty intuitive to me. A class that you implement is a class that isn't really a class yet, so you need to define it, i.e. implement it. A class that you extend works perfectly fine on its own, you just want to make it better, i.e. extend its functionality.

And they aren't really opposites. In both the implements and extends cases, the A class can call methods implemented in B. And in both cases, A can override methods implemented in B and add new methods. The only difference is that, in the implements case, somewhere in B is at least one method that hasn't been implemented yet and needs to be implemented in A.

[shaktool.livejournal.com]

My bad. I mixed up interfaces and abstract classes. But an interface is just like an abstract class that neglected to implement any of its methods.

[ekorber.livejournal.com]

interface = totally abstract class.

[(Anonymous)]

...except for not being a class.

[gustavolacerda.livejournal.com]

that was me

[ekorber.livejournal.com]

Yes, but it's entirely accurate to say "An interface is a totally abstract class, where you use the keyword implements instead of extends, and you can implement more than one of them."

If the compiler was smart enough to tell when a class was totally abstract (which I'm pretty sure is impossible in any practical sense), we wouldn't need interfaces at all. We could just allow multiple extends and require that at most one of the classes extended be a non-totally-abstract-class.

[gustavolacerda.livejournal.com]

If the compiler was smart enough to tell when a class was totally abstract (which I'm pretty sure is impossible in any practical sense)

Can't you tell from the method declarations? i.e. a class without internal curly brackets is totally abstract.

Is there any reason they shouldn't have used "extends" for both superclasses and interfaces?

'implements' = OO, 'extends' = convenience

[(Anonymous)]

... or so the language purists tell me. Lessons learned from Smalltalk and other OO experiments (and encoded in the next-to-latest OO-hype: design patterns) teach us that type inheritance is the backbone of OO. Class extension is actually an implementation detail/convenience that can just as easily be solved by delegation.

Aspects is the currently-hip way of providing the functionality that mixin classes used to give, namely added functionality. Also, some design patterns which need small code changes in different classes (such as visitors or observers) can be neatly brought together in one aspect.

-- Joost Cassee (no account yet)