Is inheritance broken?

Alex Martelli aleaxit at
Thu Mar 29 11:07:14 CEST 2001

"Ype Kingma" <ykingma at> wrote in message
news:3AC25FB7.7FD8759D at
> This code follows a rule: never instantiate a class that
> is inherited from. (In other languages your 'flat' classes
> might be called 'abstract' in order to indicate that they cannot
> be instantiated.)
> IIRC this is a design pattern in class hierarchies.

I agree.  So does C++ guru Scott Meyers, who recommends
the same rule for C++ design -- whenever you find yourself
with two instantiable classes inheriting from each other,
refactor to extract their commonality as an abstract class.

[It's also consistent with the concept of _taxonomy_ --
'leaves' of a taxonomy tree (concrete-classes in its
equivalent object model) should be a partition, not just
a cover; of course, taxonomies have their own issues,
related to those of single-inheritance constraints in OO].

Inheriting-from-concrete-classes is "pragmatically OK" in
small-enough subsystems, but mercilessly refactoring to
abstract the reusable abstractions is an excellent principle
for 'programming in the large'.  Adopting in-the-large ideas
for moderately-sized subsystems is not a must, but it may
serve you well if and when a subsystem unexpectedly grows.


More information about the Python-list mailing list