Sign in to follow this  
HappyCoder

Is inheritance evil?

Recommended Posts

I've becoming more and more convinced that inheritance is a code smell. This article explains my sentiments
http://www.javaworld.com/article/2073649/core-java/why-extends-is-evil.html
I tend to agree with it because inheritance has caused me plenty of frustrations. I really appreciate what the makers of golang did. They got rid of inheritance and make use of embedding and interfaces instead.

Am I wrong to think that inheritance should be avoided?

Share this post


Link to post
Share on other sites

I've becoming more and more convinced that inheritance is a code smell. This article explains my sentiments
http://www.javaworld.com/article/2073649/core-java/why-extends-is-evil.html
I tend to agree with it because inheritance has caused me plenty of frustrations. I really appreciate what the makers of golang did. They got rid of inheritance and make use of embedding and interfaces instead.

Am I wrong to think that inheritance should be avoided?

 

 

Inheritence works best for ideas and implementatino of those ideas.

Or interfaces you need to implement. These useages are perfect for inheritence.

_HOWEVER_

If you wish to add a new behavior, then you should review your design and seek for other options.

Many times i've read that compoisition is better than inheritence in these cases. And sometimes they are right.

Some good patterns involve with composition rather than inheritence, such as the adapter. Facade, Proxy and decorator. 

 

For most cases, strategy pattern is a better solution than inherit the class and add the behavior. 

It seperate concerns and behaviors into new REUSEABLE components. This is a perfect goal. Therefore inheritence lack in that case.

But, if you use inheritence to express a new idea from another idea, it will suit.

In example: A chair got magnified and got a new coolish look, so new data is presented such as "color of the flag", "the hamster that is sitting on it" and my favoritre "The cat that ate the hamster".

This chair doesnt need the cat as a strategy since it's its own field. 

 

There are many articles that state "XXX IS BAD, USE YYY". "YYY IS TERRIFIC, STILL USE XXX".

Don't listen to those articles. Good programmers know to valuate their tools and state what these tools are good for. 

Share this post


Link to post
Share on other sites

It is good advice to prefer interfaces over inheritance, but there are uses for inheritance too. Inheritance does get over used, probably because it is often taught too early to new programmers.

 

Personally, I reserve the word "evil" for things that are anti-patterns in all cases. For example, in C++, NULL is evil and can get you into trouble; prefer nullptr in c++11 and later or 0 in C++03 and earlier.

Edited by King Mir

Share this post


Link to post
Share on other sites

As others have said, one must distinguish between "interface inheritance" and "implementation inheritance". Speaking in generalities, the former is a good thing, and the latter almost exclusively a bad thing.

 

However, and this is a fairly large caveat, in languages such as Java which lack any concept of mixins, one ends up having to use implementation inheritance to achieve a poor-man's version of mixins... so we don't have the leeway to disallow it entirely.

Share this post


Link to post
Share on other sites

Class inheritance can break pooling of ascendant objects with immediate access, etc. but can as well be totaly neutral towards run time performance in some cases, which are feature extendings/property inflatings ... for example. It is surely good to aproach it as a "no no" and think twice before implementing it.

Share this post


Link to post
Share on other sites

Inheritance is not evil. You need it for a variety of designs and a lot of code can not be created as efficiently without it. It's evil when you use it poorly however, hence diamonds of deaths which can cause you a whole slew of logical problems.

Share this post


Link to post
Share on other sites

The article is correct, assuming you read it.  
 
Note that it is talking about "extends", which is one type of inheritance.  Java's "interface" and "implements" are another type of inheritance.
 
...


yeah, I guess when I said inheritance I was referring to extends way of doing things.

Share this post


Link to post
Share on other sites

Generally speaking, everything is evil if you don't understand it. Elements of OOP, recently hyped DoD and many other techniques - they all exists for some reason. They haven't been created to replace each other but rather to solve certain problems. Recently you may read on GD forums how programmers try to implement DoD without any valid use-case, at all cost, just because it sounds modern and makes impression of solving all world's problems. It's simply not true. DoD exists to solve certain set of problems while it may actually complicate other matters. Same goes to the inheritance. Programming is not black and white. You may successfully join techniques of using inheritance and composition etc. It's up to you what kind of architecture you built. Build it crafted to your needs not to current fashion :)

 

Answering you question I would say, inheritance isn't evil. As was mentioned above, everything may be used or abused. I agree with that 100%.

Share this post


Link to post
Share on other sites
Implementation inheritance, as provided by mainstream object-oriented languages, is fundamentally evil. I'm a little surprised that statement is even controversial.
 
This isn't a new observation. The change in paradigm here came in the mid 90's, when people started noticing the limitations and flaws of implementation inheritance, and transitioning to interface inheritance. Robert Martin's original article on the topic is a worthwhile read.
 
If you look around enterprise software, there aren't a whole hell of a lot of meaningful software projects still clinging to implementation inheritance as the default. Unfortunately, game development software is full of such warts, I think in part because many of the open source game engines were conceived of in the early 2000's, and haven't really seen a rewrite since.

Share this post


Link to post
Share on other sites

cons

large inheritance can create higher coupling between classes.

root of hierarchy becomes deprecated = cascading affect on subclasses

could reveal encapsulated items

other cascading changes = change one class have to change more

large inheritance hard to understand whats going on behind the scenes with bottom classes

 

so in other words smaller inheritance is better.

you shouldnt always avoid inheritance. especially if you want to save time doing something simple.

like creating ten different animals who each have a different traits , do you really want to have to code what an animal is for each animal or just extend the animal class for each animal.

 

id say you should avoid large complex inheritance within an API if you are working on a long term project where the team will be changing.

if you are working with the same team or by yourself for the entire project and everybody's brain can handle the large hierarchy then its not a serious problem, but still possibly a bad design.

Edited by localplutonium

Share this post


Link to post
Share on other sites

When you need to bridge two different object hierarchies it becomes an angel.

 

e.g. Suppose you were working on a project that mates Simulink to DirectShow.

You can do it with composition but that will be almost twice as work as you emulate a DirectShow filter on the Simulink side to serve as a sink for the composed filter - as opposed to directly making a DirectShow sink filter that dumps the data into the Simulink data flow (for which you would already have a base-class written to interface with Mathworks's C API.)

Edited by Shannon Barber

Share this post


Link to post
Share on other sites

A good rule of thumb is to solve any problem with the least-powerful tool it can be (reasonably) solved with. Try not to think of that in a negative light -- by using the least-powerful tool, what we really mean is the one with the least unnecessary dangers attached.

 

There are a few general power-progressions you should try to observe:

  • Prefer composition over inheritance -- that is, use inheritance only when it supports precisely the relationship semantics you want, not for reasons of convenience.
  • Prefer interfaces (interface/implements, pure-virtual classes) over inheriting concrete classes (extends, "plain" inheritance).
  • Prefer non-member, non-friend functions over member functions, prefer member functions over non-member friend functions, prefer friend functions over friend classes, in C++.
  • Know the differences between private, protected, and public inheritance in C++, and use the appropriate one.
  • Keep things in the smallest reasonable scope.

 

Those are just a few examples. Being a good engineer doesn't mean being the one who smuggly wields tools of great power, confident you'll not fuck up; Its great when one can do that when they have no other reasonable choice--and you'll still fuck up--but a trait of a good engineers is that they seek out the solutions which are exposed to the minimum set of potential hazards while meeting requirements of (in mungable order) safety, performance, maintainability, usability, and ease of engineering.

 

Language features are not inherently evil (not even goto), but they are sometimes misapplied and the more commonly misapplied they are, or the worse the repercussions are, the worse their reputation becomes. Sometimes this is exacerbated by the way that languages are taught, as is the case with how inheritance has come to have such a poor reputation. Sometimes its exacerbated by the mistranslation of programming skills from one language to another; in general, a Java programmer (or C# programmer to a somewhat lesser degree) will *way* abuse inheritance if tasked to write C++ (and they'll probably leak memory like a sieve too  :) ).

 

TL;DR; Know thy tools, and program.

Edited by Ravyne

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this