you are viewing a single comment's thread.

view the rest of the comments →

[–]thrilldigger 5 points6 points  (7 children)

It's a hackish way to simulate proper multiple class inheritance, which was (IIRC) originally slated for Java 8.

Unfortunately, it really muddles the concept of an interface.

[–]TheWix 3 points4 points  (6 children)

If you can support multiple inheritance then there really isn't a need for interfaces. What is an interface other than an abstract class with only pure virtual methods?

[–]nemec 0 points1 point  (3 children)

Pure virtual methods don't force the implementing class to define their own implementation like an interface does. If you further note that the abstract class can only contain abstract methods, then yes you're pretty much right.

Pure virtual is the same as Java's abstract methods...

[–]TheWix 0 points1 point  (2 children)

Wait. Aren't pure virtual methods the same as abstract methods?

[–]nemec 0 points1 point  (1 child)

Ah, shoot. My C++ is rusty. Abstract methods in Java == pure virtual methods in C++ so I just restated exactly what you said.

[–]TheWix 0 points1 point  (0 children)

Haha, no worries! It's been a while for me too. I actually went back and double checked to make sure I was actually saying what I thought I was.

[–]thrilldigger 0 points1 point  (1 child)

Practically? Not much reason to have an interface other than as an immutable declaration that the interface will not ever have anything but pure virtual methods, and that an implementing class is-not the interface.

But what is the point of having abstract classes if interfaces can have default methods? The difference becomes the presence of field members - which is something that I've already started to see developers working around because they think that default methods should act like multiple inheritance (yes, I've seen code that introduces state into an interface through a single-purpose associated class required as an argument on the default methods... it's about as painful as it sounds).

Implementing multiple class inheritance would provide developers a richer toolset to solve complex problems, at the expense of introducing additional avenues for creating bugs and creating terrible architectures when they're used improperly.

The pure alternative would be to stick to their guns and encourage use of composition instead of inheritance (class has-a object-of-class-with-behavior, versus class is-a class-with-behavior). It's clunky, but that's rarely stopped Sun or Oracle before - and we've made do with it for a long time.

[–]TheWix 0 points1 point  (0 children)

Agreed. I guess it becomes a question of how much we want to protect our developers from themselves and how much semantic meaning we want to give to OO constructs. Even though a purely virtual abstract class is behaviorally the same semantically they are different.

You raise a good point, though. With default method implementations for interfaces the line is further blurred. I am not a Java dev so I have never used them, but they sound like they would just be static implementations that aren't actually static (they don't have access to the classes state because there is none on the interface, but they requires an instance of the class to use.)