In a recent video on Java, Joshua Bloch states at 4 minutes 20 seconds into the video:

And then there's inheritance, and that was a marketing necessity. You know, we can argue whether you really need implementation inheritance or not.

So I wondered: how would Java look like without implementation inheritance? For example, how would equals, hashCode and toString work? Would Java have needed something like mixins instead?

  • 6
    The lack of implementation inheritance was one of my biggest complaints about having to work with VB6. – Larry Coleman Aug 9 '11 at 19:29
  • "You know, we can argue whether you really need implementation inheritance or not." I can't think of a problem implementation inheritance solves that is not solved as well or better by composition + interface polymorphism. In the "best case" implementation inheritance saves you keystrokes delegating to an internal member and can only then be viewed as a weird syntactic sugar. – weberc2 Dec 16 '15 at 18:25

With a suitable public API I can see something like the .net extension methods serving very much of the same purpose.

public static boolean equals(this Object that, Object other) {
  return (this == other);

It would take a language change, obviously, but you could get a lot of reuse with a syntax very similiar to what we have today.

  • Except you can't do anything that breaks encapsulation, which limits the usefulness. – Andy Oct 25 '15 at 18:55

For your particular example, what about simply using functions taking the object as argument instead?

toString(Object obj)
hash(Object obj)
equals(Object a, Object b)

I think people tends to be pretty extremist in what they "think" is awesome or catastrophic.

Let's be objective. Inheritance is useful in many cases. It's not a "necessity" but is quite handy in some cases. However, yes, it tends to be overused/overpromoted and sometimes introduces complexity where it shouldn't.

Can we live without inheritance in mainstream programming languages? Not really. They are an essential and useful construct. Doing without them would be a pain in the ass.

Can we find some other mechanisms which are better than inheritance? Surely. Single inheritance is very limited, multiple inheritance is a two-sided blade. But inheritance itself might not be the best route altogether. One way are the traits like in Scala, the classes like in Haskell (nothing to do with normal classes), and many other mechanisms.

However, one might go even further and asks whether "objects" are the way to go in our modern world. Perhaps something with algebraic data types and asynchronous agents would fit better the challenges of massive parallelism and expressiveness in programming languages. (Yeah, I know, this sounds like academic mumbo-jumbo, but there is actually very concrete stuff behind it.)


Google's go is an example of a language which does away with implementation inheritance while being OOP, supporting polymorphism and pertaining to your question, composable interfaces.

I think the biggest problem with implementation inheritance is the following: Consider a Stack class which could be implemented using a Queue class. You could do it two ways, one way would be to derive the Stack from the Queue and add the push() and pop() methods. The other would be to embed a Queue instance inside a Stack and use it for implementing push() and pop(). In general, the latter is preferred so have the class "contract" is never confused. On the other hand, embedding an instance inside another would be a nice way to achieve code reuse without spoiling the class contact.

The class contract on the other hand (its interface) should be composable or subject to inheritance.

  • I upvoted, but another aspect of inheritance vs composition is that you can't modify the "parent" or "component" class with inheritance. Further, you can't inherit from an interface and select which implementation of that interface will serve as the "parent" at runtime. With composition, you can do all this and more. – weberc2 Dec 16 '15 at 18:33

I can't see being such a language purist that you get rid of single inheritance, then fix it my allowing mix-ins (multiple implementation inheritance).

Good point about equals, hashCode, and toString, my guess is that either they would have the compiler default in the implementation or else everyone's tools would (somewhat defeating the purist motivations).

Since subclasses would basically become decorators I imagine tools support for decorators would become a huge priority. Whether at the end of the day things would become purer or people would just do cut and paste inheritance may never be known.


Polymorphism is the end, inheritance is a means. It's one that is pretty easily understood and I think it's pretty useful. In Java, I'm a big fan of the template method pattern which generally avoids the need for invoking super. Every time I've invoked super in Java, I felt a little dirty for some reason.

  • Inheritance is only a weird subset of interface polymorphism and composition that restricts you in unnecessary ways and gives you absolutely nothing. There is nothing you can do with inheritance that you can't with interface polymorphism + composition (including polymorphism); it just happens that inheritance implies some syntactic sugar so the programmer doesn't explicitly have to delegate (though the language could easily support this syntactic sugar for composition relationships, and indeed Go does exactly this: play.golang.org/p/jOikzf274e). – weberc2 Dec 16 '15 at 18:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.