I don’t like inheritance in Java and now I know how to explain why
I tend to dislike very very much class inheritance in Java. However, until today, it was not easy to explain why.
I’ve always said that beginners do a lot of duplication when they code, medium programmers solve this problem using class inheritance, good programmers find every possible way to abstract even more and get rid of class inheritance, sometimes even for the price of a small duplication (due mainly to java limitations).
If you search keyword extends in your code base, how many times doest it appear compared to keyword class?
[Update]There are plenty of reasons to not abuse of class inheritance. Most good developers know them. Still it takes some time and some maturity to understand. I found that a simple way to demonstrate the bad effects of class inheritance is to focus on code readability.[Update]
If you don’t agree, let me ask you to play a little game: open Spring framework sources on any complex class, eg. CancellableFormController and try to follow the code. Once you’re lost you should agree at least a bit.
Although Spring source code is very well documented, and pretty well written, I very often fail to understand the big picture. It’s the archetype of code using way too much class inheritance. Sometimes up to five or ten levels of inheritance (8 levels for CancellableFormController). It’s impossible to read: too difficult to understand which method is really executed or replaced by another. And the tools don’t help since most of those IDEs I know of cannot show a merged view of a class hierarchy. You jump from one class to another for each method.
What do you think?
Your title does not at all match your contents. I thought I’d see something about Java specifically. Instead you are (rightly) complaining about overuse of inheritance. I agree about the overuse, but it has nothing to do with the Java language.
Interface inheritance is good when applied properly.
Class inheritance is bad except the situation where an inner class extends an abstract class.
I agree. Shallow or no inheritance is best. Composition is much better. A mistake I see a lot is using inheritance to override a single method or two. Instead, passing in a interface that handles this is much better.
i think the title is wrong, its about too much abstraction. you can also use interfaces for it, i remember class that had field(interface) and there were like 7 implementations and and those implementation had the same type of field. to know what implementation is used you had to use debugger.
The issue seems to be the *abuse* of class inheritance, not class inheritance itself. Some folks try to do everything via class inheritance even when it doesn’t make sense or can be handled in better ways.
Inheritance is just like any other tool. In the hands of one who does not know its proper use it becomes a menace.
Coding is part science and part art. The overuse of inheritance may be scientifically sound but it is cumbersome for humans to read. Code, like art, should be pleasing to the eye.
I know programmers who pride themselves in the obfuscation of their code in the name of job security. These people should not be in the industry.
I agree that inheritance can result in solution which is confusing to read or follow. Some care needs to be taken when using inheritance. One example which comes to mind is the ORB classes.
com.sun.corba.se.spi.orb.ORB extends com.sun.corba.se.org.omg.CORBA.ORB extends org.omg.CORBA_2_3.ORB extends org.omg.CORBA.ORB
@Jkilgrow You are right. Readability is not universal but still it should drive every developer’s choices. Seven levels of abstract is not ok to read!
@Dave Sure the abuse of anything is always a problem. But how do you explain somebody why seven levels of abstraction is bad (even in a well written code)? My point is “just have him read te code and explain what it does”. He should be lost quickly and now he understands. I took Spring code because it is a well documentated code. So the problem is not about dirty code, it’s really about readability of class abstraction.
In eclipse, from within the editor Ctrl + o and then Ctrl + o again.
@makkapakka I didn’t know that. It’s a nice outline view of inherited methods. Same thing on source code would really help.
The most common recommended use of class inheritance is the template method pattern (refer http://en.wikipedia.org/wiki/Template_method_pattern and GoF book). The Java best practice is to keep this activity private to the class; that’s why an inner class extending another abstract class is fine. Any decent framework (Spring, Hibernate…) uses this pattern a lot – you just need to keep the pattern in mind while wading through the code.
I feel Java based design patterns and OO concepts lead to a lot of waste while writing code – it has got cruft. On the other hand, the OO model of JavaScript (and probably Ruby) is quite clean. Check them out. Functional programming solves lot of these problems by shrinking the abstraction down to a function level (equivalent to a Java “final” interface having exactly one method). Example: Clojure and Erlang. Erlang solves a lot of JVM-design issues as well.
I don’t agree with you at all.
You can hardly ever have too much abstraction in your code. Abstraction through inheritance lets you factor as much common code as possible and avoid duplication. If you’re worried about readability maybe you should use class diagrams in parallel, and get familiar with some eclipse functionalities which show you the type hierarchy.
@Johnny Keogh Abstraction yes of course! Too much class inheritance no. And the “too much” comes very quickly. Come on, be honest, if I need class diagram and type hierarchy extensively there really is a problem in the code.
Your complaint is about documentation, not inheritance.
People assume that good documentation can be substituted by reading the javadocs and bean definitions. With inheritance this type of documentation becomes even more complex.
Another problem is that people misunderstand functional, procedural, object based and object oriented programming.
Frameworks such as swing, spring, joda, hibernate, etc should all use object orientation. Applications should then then develop using composition instead of inheritance. Again, there might be key concept that makes the application unique and a well designed object oriented structure makes sense – Object orientation is about extensible behavior.
Back to the original problem, it sounds like your complaint is about documentation.
You are right. Sorry for the inconvenience.