No, inheritance is not the way to achieve code reuse!
Usually when I get to object oriented programming and I ask for characteristics of an OOP language, I get the text book mantra: encapsulation, inheritance and polymorphism - good. And then I ask what is the purpose of each of them.
What happens then used to let me a bit perplexed, but in time, since it happened so many times, I came to just expect it. Instead of getting an explanation of the purpose of inheritance for example, I get and explanation of how it works.
I am not sure how so many people go through so many years of school, which is supposed to make us better at thinking, and they fail to differentiate the “why” and the “how”.
And then I press and make it obvious that I want to hear their opinion about the purpose of inheritance in OOP. And invariably I get this precooked answer (not so nicely expressed): inheritance is the way to achieve code reuse.
No it is not! And I will explain immediately.
But before that I will let you know what this answer and its frequency tell me:
- Schools no longer teach students to think for themselves
- Teachers have little practical experience in the subject they teach
- Not everything that passes as common sense and established knowledge is actually true (this might be an understatement)
- Software crisis starts in school
Then, what is inheritance for?
Inheritance is a mechanism used to achieve categorization and to facilitate polymorphism. Using inheritance you can build a hierarchy of concepts separated in categories at different levels of abstraction. By doing this, you can efficiently use another OOP concept, polymorphism, which allows the same control code to manage all objects in a category even if they are different in their implementation.
This is the main driver for using inheritance in the design of a software system. Not code reuse.
Inheritance, while a very powerful tool, it is very hard to use right. While the rule of thumb - use inheritance for “is a” relationships and composition for “has a” relationships - is very true, applying it in non trivial situations is difficult and wanders close to philosophy. Think about this question: “Is an CircusDog a Dog or maybe CircusDog is just a role a Dog plays?”
This difficulty and ambiguity leads to wrong usage of inheritance more often than not. Because of this inheritance shall be reserved for specific situations where it makes sense. Most of the situations are covered by composition and, for languages that support the concept, by interface implementation.
Incidental code reuse due to inheritance
There is some code reuse associated with inheritance:
- Derived classes can (if desired) reuse code from the super-class hierarchy
- Control code taking advantage of polymorphism is reused for every class in a category
But this is not the reason to use inheritance. The reasons for using inheritance are modularity, separation of concerns, clear representation of concepts, categorization and polymorphism.
How to achieve real code reuse
A better way for achieving code reuse is composition and since there are lots of articles on the subject I am not going to beat the dead horse here.
As a library and framework designer avoid forcing the client code to derive from your classes. It is better to provide self contained pieces of functionality and, if needed and the language you use permits, provide interfaces for extended functionality.
The education factor
Everybody seems to think that we are traversing an ongoing software crisis and nobody knows the solution and the way out. My opinion is the only possible answer is education. What kind of education? The kind that makes you ask yourself “why”. The current education is oriented towards the “how”, and while this is important it is not by far sufficient.
Ideally the schools and later the employers should try to provide this kind of education to students and programmers. But the cruel reality will probably prevent this utopia from coming into reality: lack of experienced and passionate teachers, reluctance of employers at consuming the time of their top talent on mentoring tasks and so on.
So what is the solution? I think the solution is for us to teach ourselves by trying new things, by reading the work of good programmers, by working with them and by keeping all the time the question “why” open in our minds.
Daniel, Good post. Something I definitely agree with. While it does start in school, I see even developers with many years of experience who still don’t understand these concepts.
Great article.
A very clear explanation about the (mis)concepts of OO.
i think you are one of the person which mumbling about the class,inherintance,polymohism.
Show me the class you used.
OK, so let’s say you are using a particular GUI component configured a certain way many places in your application. One approach is to subclass it, putting the configuration into the constructor. That’s using inheritance to achieve re-use.
An alternate approach is to create a factory that creates the component, configures it, and returns it. Is that really so much better than inheritance?
If your configuration involves replacing default behavior rather than mere data values, it will depend whether the component has a configuration method that accepts an interface or closure to provide the behavior, or whether it simply has a non-final method that can be overridden. If it’s the latter, then inheritance _is_ the proper way to re-use the component. (And without closures, the first method is likely to involve painful amounts of boilerplate.)
The real issue is whether the interviewee actually understands program abstraction techniques, or whether he has simply memorized the appropriate sound-bites.
@Frank Silbermann
Hi Frank and thank you for the input. What I am saying is not that you cannot achieve code reuse through inheritance. You can as you pointed out.
But this is not the main driver for using inheritance. You picked a very clean cut domain with the GUI example. But even there you don’t use inheritance because you need some code from the parent class. You use inheritance because the derived class “is a” parent class with some modifications or additions.
I very much doubt you would derive a Button from a DialogBox just because you have some nice code to display an icon in the later.
You use inheritance to extend, modify, categorize a component, not to reuse it.
Inheritance is the way to avoid duplication of the code. Common code goes to superclass. GUI is a good example.
Good point (http://en.wikipedia.org/wiki/Taxonomy).
“The reasons for using inheritance are modularity, separation of concerns, clear representation of concepts, categorization and polymorphism.”
I think ‘reusability’ might be a common shorthand/aggregate of these concepts for someone who’s not as articulate, or familiar with business cases, as you are. If a codebase does not have strong foundations in the reasons above - the first two especially - it will not be reusable.
You’re correct that they’re not synonymous, but since one depends on the other it strikes me as pedantic to penalize someone for using the term as a synonym (provided they can grok the subtle distinction once it’s pointed out to them).
It’s blog posts like these that make me realize how lucky I was to have good teachers in college. Now that i’m working professionally, It makes me look back and realize how much they really taught me. Good job on pointing out the nuances and deep intricacies of Inheritance in a software system. People here on the blog seem to be going back and forth over the semantics of the Lexicon. Anyone can use words - It’s the understanding of the underlying concepts that makes them useful, and I think that’s what our author is trying to get at here. “A rose by any other name smells just as sweet.” I can’t disagree with the author at all, re-use is not the driving force in inheritance ever, simply by defining an object class the code becomes re-usable.
(Graduated 2000, University Wisconsin - La Crosse)
[...] The inheritance relationship is one of the strongest coupling relationships we can have in OOP. Everyone knows that coupling is bad and cohesion is good, but we still couple like mad via inheritance. We do this for a number of reasons, but one of the big ones is that very few college grads seem to get taught this in school. It makes me wonder how many undergraduate compsci teachers actually get it. Daniel Pietraru wrote a bit about this and how he has used inheritance questions as interview questions. [...]
Inheritance enables both the categories of objects you are talking about and then polymorphism but it also enables code reuse just as easily. Inheritance is for both and both are possible without inheritance. I don’t particularly like inheritance though I like both polymorphism and code reuse. I feel sorry for your interview candidates as you are judging them based on your thoughts on the situation. They are right when if say that inheritance allows for code reuse and that is one of inheritances purposes; however, it isn’t its only purpose.
I disagree that the solution lies with schools. There may be exceptions but most schools encourage rote learning and passing tests - jumping over hurdles to get a piece of paper. I think an apprenticeship type system would work better, most people learn by doing things that have real value.
Thanks for the post.
You work at A* right? And you’re pretty young, right? Because what you say is bulls**t. You don’t have enough experience to be making BS claims like this.
As an “experienced” developer, I become sad every time I see the “blind leading the blind” in software development.
This is largely why software _really_ sucks these days, why multi-GHz machines feel like the original IBM PC.
I don’t blame you, Daniel, for all of this, but I can tell from the way you think that you have met the enemy - and he is you!
But what’s the point of categorization and polymorphism? The value of a “hierarchy of concepts separated in categories at different levels of abstraction” is that you can deal with things at the highest level appropriate, rather than repeating your logic several times at a lower level. That sounds like code re-use to me.
While I agree in principle, inheritance is a very broad subject. The sheer number of different inheritance-mechanisms available make agreeing with the article problematic for me.
The idea that inheritance is required for polymorphism certainly isn’t true, even within the set of object-oriented languages. Most dynamic object-oriented languages could happily accommodate polymorphism without any form of inheritance.
What’s more, the idea that inheritance is a means of classification isn’t entirely accurate either. Many inheritance-mechanisms don’t arrange classes hierarchically. Many don’t even have classes to arrange.
It’s my firm opinion that those unfamiliar with the subject should refrain from writing articles bewailing others for not being familiar with it. Sorry.
@Joe
Hi Joe
you are a very upset man it seems. Maybe what I say is bull but certainly you don’t bring any kind of proof to support your claim. And this disqualifies your comment. As an “experienced developer”, as you claim to be, you only proved to know how to use Google. I know too, and I found this sample of a comment you made on another article: http://www.ibmsubnet.com/community/node/22936
Since this seems to be your style I stop it here.
@ Mark Lee Smith
I know there are hundreds of programming languages out there, each of them with their little quirks. But my post was specifically about inheritance in classical OOP languages. And if you look around you will see this site is mainly about Java. Also my post is about clear and practical understanding of concepts in these languages that are actually used in the industry.
By the way, I didn’t say inheritance is required for polymorphism. I said that a reason to use inheritance is polymorphism.
I take it you are pretty young, probably still in school and you look at all this from a very theoretical perspective. But Java is not Hula.
So in the end I wasn’t sure how do you agree in principle but disagree with what the article says. Do you use inheritance mainly for code reuse in Java or C++? Please give me a practical example and tell me why is good.
@ Tom
There is value in what you say but the main value is in clearly mapping concepts from the problem domain in your code. Code reuse is incidental. You don’t need inheritance to write reusable code. In languages that support interfaces you can do without inheritance most of the time.
While I’m quite sure your interviewee didn’t refer to this pattern, I want to throw it into the discussion:
Private inheritance in C++ models the has-a rather than is-a relationship and is quite useful for code reuse (binding code to the construction and destruction of an object, (partial) interface implementation by inheritance and some more..
Code words are mixin(s) in C++
Daniel, fully agree with every bit of what you say.
Thanks for sharing,
/SD
Hi Daniel,
Sorry for any confusion: as I’m not familiar with the website I took the article at face value.
I release that you were referring to standard hierarchical inheritance, but this should be clearly stated since “inheritance” refers to the concept in its entirety. There exist many more inheritance-mechanisms that don’t reflect arguments than do. The only property inherent in all inheritance-mechanisms is in fact code-reuse…
I’m not a fan of standard inheritance, as you must have gaged from my website. I most certainly don’t consider it as a viable means of code-reuse. I am also well aware of the Liskov substitution principle, and how it can be applied to produce reliable, cohesive code. And, I know why it should be applied. That said concatentative, composite and selective inheritance-mechanisms are very well suited for code-reuse, and should be applied to this end (when appropriate).
All of this is of course academically supported; a selection of papers regarding inheritance can be found at del.icio.us/netytan should you wish to read up on this subject. I have more to post so check back in a couple of days.
For the record: I’m 23 years old and currently perusing a degree in computer science at the university of Hull in the UK. As part of my dissertation I’m designing a rather unusual object-oriented language called Hula. A prototype should be available at some point over the summer if anyone wants to try it. Daniel, you’re welcome to see the code then. It will be a mixture of C and Objective-C :).
If you have the time I would love to be interviewed by you; it would be a useful and interesting experience I’m sure. If you’d like to contact me my email address is: netytan at gmail.
You realize that you’re totally setting them up, right? This line of questioning is a total sucker punch.
By starting with a lame question like “characteristics of an OOP language”, you’re putting them into “trivia questions from CS textbook” mode, and “code reuse” is what most of these textbooks say. And then you fault them for it?
Suppose, OTOH, you had asked something like this:
- Tell me about the last program you wrote outside of work.
- What OOP principles did you use?
You would probably hear a *very* different answer for the latter.
@ ken
This post is not about the dynamics of an interview
Of course I don’t just blurt a list of bullet point questions and look for yes or no answers or for answers that match to the comma the text book. Each discussion between people evolves based on the subject, their background, their knowledge on the subject etc. In this post I just generalized my question. What is important is the answer I get no matter how I ask or suggest the question. If you read the post, I don’t fault them for it. I fault the learning system.
And by the way, I always explain my position and most of them click really fast. This just shows the value of being exposed to the motivation behind concepts not only to how they are used.
No, tooltip popping up throughout body of post is not the way to encourage readers to stick around. WTH?
[...] about to make. For the sake of good authorship, I am citing his work as it surely influenced mine. No, inheritance is not the way to achieve code reuse! Thanks Daniel! Keep up the great [...]
Excellent post Daniel! I couldn’t agree more!
“I didn’t say inheritance is required for polymorphism. I said that a reason to use inheritance is polymorphism”
So in an abstract sense, inheritance is used because it enables another programming need/technique/requirement/whatever. You believe that using inheritance to implement polymorphism is good. It just so happens that inheritance enables various other things like, for example, code reuse. Can you see that, since inheritance is not needed for either polymorphism or code reuse, the arguments for using inheritance to enable polymorphism and/or code reuse are analogous?
“I always explain my position and most of them click really fast”
Seems like you are looking for sheep. Too bad your are misleading them in exactly the opposite direction you think they have been lead. The reality is the middle road shows the true capabilities of inheritance.
The more code I write, the more I believe that inheritance (of implementation, not of interface) is almost always the wrong answer to any problem.
The moment you inherit, your derived and your base class are now in a death-grip you can never break.
As the truism goes, only use inheritance when you are sure there is an “is-a” relationship between the two classes - but you shouldn’t always use it even in that case. Delegation is often a better choice for re-use of object behaviour, but perhaps you don’t really need “classes” much at all, how much easier life can be if you do a lot of heavy lifting with static (== state-free) functions.
@Mayson Lancaster
Hahaha
thanks, I didn’t notice the tooltip. In my defense this is the first Wordpress theme I ever wrote. I might have screwed up somewhere. I’ll look into it.
@Ted Henry
“If you give me six lines written by the most honest man, I will find something in them to hang him.” - Cardinal Richelieu
You can twist my words in many ways, but I think the message of the post is very clear. And you can agree or disagree with it based on your experience and knowledge.
To put the message in other words, I never look at a big class full of juicy code and think to myself - I better derive from this class to reuse all that succulent functionality.
Good post Daniel!
Some people already find inheritance to be too limiting by forcing a single ontological decomposition onto a problem domain (http://www.research.ibm.com/hyperspace) - it’s the so-called “tyranny of the dominant decomposition”.
Whether or not one agrees that OO is tyrannical, it is a little tyrannical to force one’s own decomposition onto a third party (when it can be avoided). One also exposes the user of one’s code to possibly fragile base classes (http://www.cas.mcmaster.ca/~emil/publications/fragile/).
I think you’ve hit the nail on the head. Inheritance is a useful concept for building ontologies in one’s own code, but outside of domains like GUI programming, one shouldn’t be building ontologies for other people.
Modern OOP languages has (at least) two types of “inheritance” with orthogonal meaning and equal rights:
1. inheritance of interfaces — inheritance as method to denote separation of concepts. this brings to the code the harmony, regularity and clearity.
2. inheritance of classes — inheritance as mechanism of code resue. this is programming trick for save coding time (like reusing of libraries).
there is no “more important” of them. // you was right then spoke about the educational crisis. i’m sorry for my silly english.
@Wynand Winterbach
Thanks. This is exactly what I mean. When faced with a library that tries to force me to derive my classes from library classes my skin crawls
I always end up writing a virtualization layer trying to alleviate the fragility but there is no perfect solution unless the problem solved by the library is very generic.
Inheritance is not THE way to achieve code reuse, but your students are correct in that inheritance is A way to reuse code. By definition, the base class(es) of an inheritance tree will contain code that applies to all derived types, hence reusing code among multiple classes. Isn’t that the definition of code reuse?
You are certainly correct that composition is a better way to reuse code, but only in cases where composition makes sense. For multiple classes that represent variations on the same thing, then inheritance might be a better way.
I think the article is spot-on. Most people confuse inheritance with code reuse. This I have personally experienced in many cases where people just make a base class for functions which could have easily been put in a utility class. And once you make a base class like that, everyone has to derive from it to take advantage of it where as a utility class would have been much better.
And as you pointed, code reuse is an added benefit of inheritance (in some cases) but it should never be the only benefit.
Good Article I must say.
Ok so it’s not just me who thinks Universities have a poor standard of teaching ….
I’m a student and we rarely get taught HOW to think, but we are rewarded for memorizing these “textbook mantras” …
Daniel, I would actually argue that you are wrong, and your students right.
In university I was taught to use inheritance as a categorization technique. However, in real life there are often more than one way to categorize the object hierarchy of an application, so this rarely works out well in my experience.
After 10 years of pro software development I observed that I stopped using inheritance as a categorization technique, and now mostly use it for code reuse. It is not the only way to achieve code reuse, but it is *one* way, and definately a valid one.
I’ll actually be writing a post on this topic (or already have somewhere on my disk). I’ll make sure to link to this post for an alternate opinion.
I am confused after reading this
http://www.peterprovost.org/blog/post/Inherit-to-Be-Reused2c-Not-to-Reuse.aspx
and your post.
Are you saying GoF’s Template Method is not something we should use at all?
@Harry
No, I am not saying not to use GoF’s Template Method. Actually that is a very good use of inheritance and abstract classes. While you will get some code reuse with the Template Method pattern this is not the reason to use it. The reason to use it is to define structure and enforce flow. But I prefer to use this pattern in closed frameworks. I never expose classes like that in APIs since I don’t want to force the clients to derive from my classes. If I want for example algorithms to be specified by the client code I am better off with interfaces in the API and inversion of control as a framework.
My post is about “reason”. Use inheritance if it makes sense, not for code reuse alone. Keep in mind all the time to avoid dogmas :). Use any pattern or technique if it makes sense in your particular case. Ask yourself if it makes sense and what are the motivations.
@Jakob Jenkov
Hi Jakob
we already have a pattern here so I was sure you will disagree. I will wait for your post but, in the meantime, can you provide a sneak peak and give me a concrete example where you use inheritance solely for code reuse?
And I am sure what you vs. what my new grads mean by reuse is pretty different in concept and context.
Do your newly minted graduates tend to say (in meaning, as I know you were paraphrasing) that “inheritance is the way to achieve code reuse”, or “inheritance is _A_ way to achieve code reuse”?
Just curious, as IMO, the article (grammatically, as in definite vs. indefinite article) makes a _huge_ difference.
I also agree with Ken, and I will give you that “this article is not about the dynamics of an interview”.
However, even as an developer of 14 years, I still have before me the difficult task to gauge whether or not the interview is of the type “guess what I’m thinking”, or if the interviewer can themself think enough on their own to recognize an answer that falls within a “correctness continuum” .
Sounds like the “Object Oriented Programming Has Failed Us” post I did about a month ago.
Schools CAN’T teach programming (or anything else technical) because what we are doing in real life takes about 20 years to trickle down into the educational system. In computer time, that’s the dark ages.
Sorry, I feel I have to disagree here.
Implementation of interfaces gives us polymorphism.
Abstraction gives us data hiding and interface definition.
Inheritence gives us reuse.
If you were going to argue, “Inheritence doesn’t JUST give us reuse, it also allows us to have polymorphism”, I’d still argue that you can obtain polymorphism by defining interfaces, not inheritable classes.
The *purposes* of inheritence are several, but polymorphic behavior (the ability to override an inherited member) does not necessitate, even though it often does, a custom implementation.
The primary goal of *inheritence*, which has everything to do with what carries over which includes not just interfaces but also implementation, is to give an object everything it needs to define what it is before you begin tailoring it.
If I have a VEHICLE, and I inherit it with CAR and TRUCK, I can write 99% of the implementation of both CAR and TRUCK in VEHICLE, where CAR would have one set of dimensions, shape, and mass, while VEHICLE would have another. Inheritence allows CAR to only have three lines of code: “Shape = {1,2,3} (whatever); Mass = 10; Dimensions = {5,10};” Again, whatever. A well-designed implementation of VEHICLE will adjust accordingly.
An Interface, however, will have NO inference of implementation. If VEHICLE *implements* the interface IVEHICLE, and IVEHICLE defines the method “Drive()”, then you have polymorphic behavior that you can invoke against both CAR and TRUCK. That, however, is NOT inheritence. That is *implementation*.
Experience drives the truth in this matter, whether or not the schools have failed us. Learn the difference between an Interface versus an inherited Class.
@Troy DeMonbreun
Hi Troy, the answer varies from person to person. My question is usually formulated “What do you think about inheritance? Why would you use it?”. Most of the answers unfortunately go straight to “reuse” without any reasoning other than “the code in the parent is also accessible in the child”. And indeed I didn’t want to write a post about interviews.
@Dave
Your article is very interesting but I am not sure if I agree with the conclusion. I will try to comment there.
@Jon Davis
Don’t feel sorry
First of all we would have to clearly define what “reuse” is. But that is a big topic for a comment. I agree interfaces give us polymorphism. But not all languages have the concept.
I still think inheritance is useful to create hierarchies of concepts and then to facilitate polymorphism and it should not be used for the sake of reuse. The kind of reuse you describe can be implemented better with composition.
With your example you can run into trouble in many ways. Your VEHICLE has Shape, Mass and Dimensions. But so has a BUILDING and an ANIMAL. So plain code reuse is not the reason to use inheritance. Otherwise you would derive CAR from BUILDING. It still gives you Shape and Mass. The reason you use inheritance is because of the “is a” relationship. This my point. Reuse is a side effect. With inheritance you want to create these hierarchies of concepts and then work with them at a higher abstraction level. The problem with the code reuse as the result of inheritance is that it is not stable. You have to accept that. When your requirements change and you have to include in your VEHICLE hierarchy PLANE, ROCKET, SHIP and SKATE you will have to shuffle your code and modify the parent classes more often then not. And in that situation you are better of if the code reuse was done by composition in the first place.
“What do you think about inheritance? Why would you use it?”. Most of the answers unfortunately go straight to “reuse” without any reasoning other than “the code in the parent is also accessible in the child”.
[end quote]
So, as re-use is a valid answer, your problem is with their reasoning?
@Daniel,
You bring a very good point. In fact, as I’ve become more experienced with developing extensible/reusable/maintainable code over the year I find an almost complete lack of inheritance beyond interfaces. As you point out, and in my experience, composition creates a far longer-living clean code base then taxonomy based designs.
With composition based designs I can change some business logic in one place, one place only, and not have to worry about how that change will affect a deep heirarchy of children. Going with your dog example, isn’t a Circus Dog really just a specific setting of properties on the Dog object? Not really a new concept of a Dog.
Creating a useful example, you have a Circus object and a ICircusShow interface. The DancingDogShow implements the ICircusShow and takes a Circus and Dog object. In a composition design, adding a TalkingDogShow is fairly simple. Perhaps down the road the TalkingDogShow and DancingDogShow are combined into a TalkingDancingDogShow.
Now imagine the same scenario above, but instead we have an inheritance structure of DancingDog and TalkingDog derived from Dog. When you go to refactor the shows into one you have to also modify the inheritance structure for the Dog. Do you remove the two derived Dogs and create a new TalkingDancingDog? What other parts of the system will now depend on this? Should a TalkingDog now inherit from a DancingDog?
I think it’s pretty obvious that folly lies this way.
http://www.berniecode.com/writing/inheritance/
After reading this article, I think I understand where you’re going. Reuse *can* be achieved through inheritance, but it is not the desirable way to do it, given better methods or patterns of doing so — because it limits/traps the developer in cases like the ones mentioned, and actually causes/forces code redundancy.