• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 399
  • Last Modified:

Is inheritance evil?

I've just been told by work not to use any inheritance.  I've been trying to do some reading about it and i just can't get my head around it yet.  Allot of the people who post/blog have been burned in the past, but i'm still yet to be burn't.  I guess that's from my lack of large projects.

So is it really that bad?  Any hints/examples/suggestions on what i can do to get my head around this?

I know their is no simple answer, so i'm happy to share the points around =)

Thanks for any help.
  • 2
  • 2
  • 2
  • +3
6 Solutions
inheritance is not bad. It serves the purpose of reuse the code that we already developed and speedups the developement.

have a look on this link to find out more

Richard QuadlingSenior Software DeveloperCommented:
Inheritance is a great tool. But as with all tools, use with caution.

I've come from Delphi to PHP.

I have a base object class which supports the idea of "ownership". As part of the shutdown phase any object which "owns" another destroys its "children" first.

That way you have a First In Last Out mechanism.

Ownership can be transferred.

If you take something like a window with lots of controls which may have more controls, if you just free the window without freeing the controls, you may well lose access to the controls and you now have a "leak".

Inheritence from my base object solves that problem.

In my mind inheritence solves many problems. Create a generic base class and extend it to become more specialised.

I have this a lot ...

abstract_class_which_would_work_if_it_had_some_config_data implements config_interface

real_class extends abstract_class_which_would_work_if_it_had_some_config_data implements config_interface

Here the real class extends the abstract class but also requires the use of a config_interface to be able to consistently pass data upto the parent (I can use my config_interface between any number of base and special classes knowing that I always have the appropriate methods at hand).

But, one of the major problems I have is multiple inheritence. This is not common in many languages.

If you develop a "deep" tree of inheritence, bubbling functionality from the base to the outer most class can take a while (in cpu terms).

If you move code from 1 level to another, the knock on effect may be unpredictable.

In the past I've used a class flattener, which takes the "deep" objects and constructs a single class with no inheritence. This is then used in the main code.

Sure, you end up with a LOT of duplicated code, but a single class does all the work, so determining which "level" to look at is taken away.

So, create with inheritence but create new classes when you are ready for running which are flat.
Jaime OlivaresSoftware ArchitectCommented:
In my honest opinion, those saying that inheritance is evil, have few skills about Object Oriented programming (vb programmers maybe?), but notice if you are working with pure database applications, then inheritance will not be necessary in most cases.

Inheritance is useful in many cases, but some book authors doesn't contribute to clarify with a real world example, insted they use stupid examples as Cat is derived from Animal or Car is derived from Vehicle.
Multiple inheritance, countersense, could be confusing and an error source, unless you are an experienced programmer. C# doesn't support multiple inheritance, C++ does.
Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

Craig WagnerSoftware ArchitectCommented:
Saying inheritance is evil is like saying hammers are evil. They are both tools that can be very useful when used appropriately.

When you are developing an application and you find you are writing the same bit of code (or copying and pasting the same bit of code) over and over again between your classes, you either have a candidate for inheritance or for a utility class.

If the classes are related in some way (you're creating an HR system and you have Employee, Manager, Contractor) and you keep copying your Save method from one class to another, you probably have a candidate for inheritance.

If, on the other hand, you're needing to calculate the day of the week given a particular date (not a good example because the framework already has that) from several disparate classes (e.g. Employee, Order, Paycheck) then inheritance isn't the right solution.
HonorGodSoftware EngineerCommented:
Inheritance, in and of itself is not evil.  However, it may depend upon how the base classes were implemented.  I have encountered situations where performance penalties were encountered because of poorly architecture of base classes.  For example, while working with an early implementation of a C++ String  class, the way in which constructors and destructors were allocating and freeing storage associated with temporary values was causing an enormous (overhead) penalty for all descendant classes.  So, be careful from where the classes are obtained.
Jaime OlivaresSoftware ArchitectCommented:
Those allocation problems usually found on C++ classes are infrequent in a managed environment, unless you are handling some unmanaged object.
UnexplainedWaysAuthor Commented:
I really liked the example of the "Executive and Worker", really put it into perspective.

With the class flattener, when you make a change to the "base" class, do you have to re-gen the files and put back in the extra code again or is it smart enough to just change the required parts?

you were right about the vb ;) and you were right about the examples.  Thats all they showed us @ uni, and then it's fend for yourself.

Another email was sent around saying that the "is evil" might of been a bit harsh and said some similar things to you.  I do like your example of the utility class btw.

All classes will have been generated inhouse, just some of the creators might not still be around.

UnexplainedWaysAuthor Commented:
Oh and sorry for taking so long to reply, i've been waiting for a time when i could sit down and really think about what you wrote.  I've skimmed across the posts as they came but wanted to give them the time they deserved.

Thanks for all the help =)
Richard QuadlingSenior Software DeveloperCommented:
The flattening is a process you run to build your classes. Like compiling. You do this prior to running the application. Sure it is another step to take for development, but at runtime, 1 object does 1 task and is flat - no inheritance, dependencies, etc.

There would be little point in having the additional overhead of at run time - though, caching could be used to deal with it. The issue would be that the application would be running, effectively, untested classes.

abstract base
class x extends base
class y extends x implements singleton

A flat y is singleton_y_x_base (just an example).

Now say I could flatten at runtime, the new class would not be code I had written. If the flattening was done at runtime for development only, then that is fine as long as the flattened classes are the published ones.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 2
  • 2
  • 2
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now