[Tutor] Follow up to 'class data'

alan.gauld@bt.com alan.gauld@bt.com
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 
anything up!

Alan g