Is inheritance broken?
Alex Martelli
aleaxit at yahoo.com
Thu Mar 29 04:07:14 EST 2001
"Ype Kingma" <ykingma at accessforall.nl> wrote in message
news:3AC25FB7.7FD8759D at accessforall.nl...
[snip]
> 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.
Alex
More information about the Python-list
mailing list