While PolyMorphism and inheritance are clearly distinct subjects, it might be useful to clarify their relationship. The discussions on PolymorphismAndInheritance thoroughly relate the two. Yet, on WhatIsDelegation (and then ConfusionAboutInheritance), this question struck me as relevant (but beyond my knowledge): does non-polymorphic inheritance exist? If so, what is it used for, and how? -- LucasAckerman

Private inheritance in CeePlusPlus. A rather advanced technique.
''Hey, no skimping on the advanced techniques. Lets go talk about PrivateInheritance''

It also highlights that the two are separate issues, since polymorphism exists perfectly fine without inheritance and vice versa.

''Ah ha! So by deduction, inheritance is not fundamental to ObjectOrientedProgramming (which is polymorphism centric).''

----
Some things that non-polymorphic inheritance is useful for:

* Implementation reuse. Not often done, as composition is frequently a better choice for this, but non-polymorphic inheritance is useful if some other class does ''almost'' what you want, you need to change it, and you don't need the two types to be substitutable for each other. Best done when the "source" class is stable; as this introduces a high-degree of coupling between the two; changes in the "source" will surely break the inheriting class.

* Design iteration. In some ways, a specialization of the above. You need to modify some class A to fix a problem or add a feature; it is decided to leave A alone and introduce a new class A'. Depending on whether or not A' must be substitutable for A, non polymorphic inheritance might be a good technique. Again, implies a high-degree of coupling.

----

''Ok, lets reiterate. Is it fair to say that the most traditional, reasonable, safe things to do with inheritance all involve polymorphism?''

I'm not sure it is. Wouldn't this be useful for MixIn''''''s? There are many times you need implementation reuse without polymorphism.

''Good example, but how are mixins implemented? Aren't they done by: inheritance(!), or AspectOrientedProgramming, or preprocessor macro silliness?''

By inheritance, but as the page title implies, not all inheritance is polymorphic, nor needs to be.

''Erm, that's right, my reasoning was circular, and you beat me to the re-edit. One more try here...''

''Let's instead say that implementing mixins by inheritance is a form of delegation, but not polymorphism, since the definition (on WhatIsDelegation) of polymorphic delegation requires that we invoke a layer of indirection. Mixins are thereby arguably a short-circuit alternative to using indirection.''

Or.. they're classes constructed lego style, and are more than the sum of their parts. I just say that because I have no idea what you're trying to say. ;).

''Bingo. The point is that classes constructed LegoToy style are not inherently polymorphic. This is true specifically because there is no implicit indirection. That is, these lego components are not wrappers derived from somewhere else, they're included whole. Does that make sense? The inheritance here is "include a lego piece," not "derive polymorphic behavior from a lego piece."''

----

Here's a tough follow-up question: does this mean MixIn's are not OO? A MixIn is not necessarily polymorphic, because it does not require indirection. It is, however, a means of encapsulation. So, this may depends on whether you believe encapsulation is a fundamental OO concept on the same level as polymorphism.

''Depends.  Is encapsulation-and-reuse central to OO, or Modular?  OO is, as it was originally designed, an extension of the Modular paradigm.  If so, then MixIn''''''s might not be very OO, in the sense that they aren't really part of the concepts ''added'' to Modular Programming by OO.''

''And then, of course, one realises that you could have MixIn''''''s for modules.  That wouldn't be OOP at all, but it would still have MixIn''''''s.  So, no, MixIn''''''s are not an especially OO concept.''