Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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?

share|improve this question
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

5 Answers 5

up vote 4 down vote accepted

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.

share|improve this answer
+1...because I LOVE extension methods. – Aaron McIver Aug 9 '11 at 20:03
Except you can't do anything that breaks encapsulation, which limits the usefulness. – Andy Oct 25 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.)

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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