6

I've been told recently a good practice in object oriented programming that you should always allow inheritance from your classes. I really don't think so, but I have no solid arguments on my mind.

Real-world examples of blocked inheritance:

  1. No C++ STL class (specialized class template) allows inheritance (having non-virtual destructors).
  2. Java has its final class modifier that applies to many standard components, like java.lang.String.

Possible reasons I think are:

  1. Security, since subclass might have access to sensitive internals. (I don't think so -- they won't access private members.)
  2. Performance, since a subclass could mess up our efficient implementations by overriding some of the member functions. (Children won't override non-virtual functions.)
  3. To enforce composition over inheritance. (I fully agree. We shouldn't favor inheritance when it's not needed.)

So my question is: In what circumstances should I intentionally block inheritance?

Puppy
  • 144,682
  • 38
  • 256
  • 465
Janusz Lenar
  • 1,690
  • 2
  • 13
  • 19
  • 7
    I've never heard of the rule to "always allow inheritance from your classes" and vehemently disagree with it. It sounds more like an urban legend than a true "rule". – Hovercraft Full Of Eels May 05 '12 at 17:48
  • 4
    The general guiding principle of library design is that it should be easy to do the right thing and hard to do the wrong thing. If there's a real chance that people might accidentally and detrimentally try to inherit from you, you can pursue this idea, but otherwise don't bother. – Kerrek SB May 05 '12 at 17:48

3 Answers3

5

In fact, the practice that I try to follow, and that Josh Bloch recommends, in his Effective Java book, is exactly the inverse rule of the one you've been told: Unless you have thought about inheritance, designed your class to be inherited, and documented how your class must be inherited, you should always disable inheritance.

I would recommend reading this chapter of Effective Java (you won't regret buying it), and showing it to the person who told you about this rule.

The most obvious reason to disallow inheritance is immutability. An immutable object is simple to use (only one state), can be cached, shared between many objects, and is inherently thread-safe. If the class is inheritable, anyone can extend the class and make it mutable by adding mutable attributes.

Alex Lockwood
  • 83,063
  • 39
  • 206
  • 250
JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
  • I won't be needing to show the book chapter. I'm going to show answers on SO :) But thank you, excellent reference. – Janusz Lenar May 05 '12 at 19:05
3

Well for starters, only disallow inheritance if you are positive that you don't want others to be extending your class. Preventing inheritance for trivial reasons (such as performance) is usually not recommended, as code reuse often outweighs the small performance gains you can achieve by marking your class final.

That being said, here are several examples when you might want to explicitly prevent inheritance:

  1. You are writing a commercial, closed-source class, and you don't want people to be able to change the functionality down the line. This is a good reason to prevent class inheritance, as you don't want to have to give support for it later on if people have overridden your methods and/or extended your classes, and are complaining that they are getting unexpected results.

  2. You are designing an immutable class. By marking the class final, you are preventing subclasses from compromising the immutable behavior of your class. For example, if you were allowed to subclass String, others could make their own implementations that allows Strings to be modified. Now no code that takes a type String can be certain that the object is immutable.

  3. You want to force composition over inheritance. This is desirable when you want to avoid tight coupling between classes (i.e. you don't want groups of classes that are highly dependent on one another).

  4. You want to encourage inlining by the compiler. Marking classes and methods as final may result in small performance gains, as it will ensure that Java doesn't have to look up the right class method to invoke for an object at runtime. Non-final methods are marked as virtual so that they can be properly extended if needed, final methods can be directly linked or compiled inline in the class. Note that the performance gain you can achieve by doing this is often insignificant (especially if your class' methods are large).

Community
  • 1
  • 1
Alex Lockwood
  • 83,063
  • 39
  • 206
  • 250
2

Just my 0.02 on this...

Allowing inheritance on a class allows people to deal with unforeseen issues. (ex. the monkeypatching that often occurs in RoR. It can be ugly but it's reality vs. pedantry). Having said that, I'm not a big fan of gratuitous inheritance. The relationship between base and subclasses can be brittle. Deep inheritance hierarchies are hard to grok.

One case I can think of disallowing inheritance is enforcing immutability. This is important for things like the Java String class.

seand
  • 5,168
  • 1
  • 24
  • 37