[Tutor] Follow up to 'class data'
Wed, 5 Dec 2001 11:45:21 -0000
> > it is much harder to ensure that a code fix in one place won't
> > cause damage some place else that inherits the changed code.
> Let's say you inherit B from class A. If you change A and it
> messes up B, the way I see it, could mean 2 things:
Way too high level.
The problems tend to be in tiny details like:
method X does something and as a side effect sets a member
field to some value, say -1, to indicate a NULL result.
The maintainer discovers a flaw where -1 should be a valid result
so in his/her 'fix' sets the field to the "right value", say None.
However unbeknownst to the maintainer some other project
uses his class and relies on the field being set to -1 and
is not aflicted by the original bug that caused the maintainer
to check the method. Now the 'fixed' version goes live and the
second project develops its own bug.
Configuration management can solve some of these issues but if
the second project needs the fixed version as well then we are
stuffed! The problem is the classic one of global variables.
Classes effectively use global variables when they modify
class member data. Although they are protected within the
class namespace they are still globals so far as the class
methods are concerned. When you get a lot of different clssses
inheriting common functions it becomes difficult to keep
track of the impact of these side effects.
Imagine a class hierarchy 7 levels deep using multiple inheritance.
Then imagine someone chaging a single method say 1 layer off the top
and trying to see what the impact is in all the layers below....
In a network management project some years ago we had just such a
scenario. Each network element (there were over 50 of these leaf
node classes) inherited 35 parent classes. If you had to change
a single method of one of those 35 base classes you had to check
out all 50 of the leaf nodes to make sure you hadn't screwed