Taxo Mania
Taxo ManiaBertrandMeyer describes Taxomania in ObjectOrientedSoftwareConstruction. The compulsion to introduce unnecessary distinctions between objects leading to an overcomplicated class hierarchy.
Major indicator: classes that add nothing new.
To paraphrase BM's taxomania rule:
BM's example of the multiple inheritance on page 544 (the FrenchUSDriver class) is an example of such a combinatorial explosion. (The class inherits Driver from both FrenchDriver? and USDriver.) What about the UKFrenchUSPakistaniItalianDriver class, and is that the same as FrenchUKPakistaniItalianDriver?
Split this example into two distinct roles here, Person and Licence (with suitable single country subclasses) and the multiple inheritance problems go away. Shared attributes used to be shared because they belonged to the Person role (e.g. "name", "dob"...). Attributes remaining in Licence will need a separate instance per country.
Associate each Person with n Licenses. This association may well be managed by a separate class. You can even make the association 1 person to 0..1 license, qualified by ISO country code.
Common ways of refactoring such models to reduce class proliferation:
The application of inheritance here isn't even appropriate: the lifetimes of Person and Licence will vary. The original account doesn't even allow representation of a Person who can accumulate or lose licenses over time.
I think that the original example introduces a whole raft of new classes that add the same kinds of data and the same kinds of functionality, yet the model doesn't reach closure: you must keep adding classes for each possible licensing permutation.
There is no meaningful distinction between many of the class permutations that can be introduced: (e.g. UKFrenchUSPakistaniItalianDriver and FrenchUKPakistaniItalianDriver). Despite it's size and complexity, the object model doesn't express all relevant conceptual structures in the domain. It reeks of a classification mania.
Similar issues are addressed in LimitsOfHierarchies. I think that perhaps there is no true, safe IS-A in almost everything encountered in software engineering. Whether hierarchies are a ConvenientApproximation? or not is another issue.
If I were a cynic ;-) I'd say that this problem has been contrived to bring about a multiple inheritance "crisis" to make Eiffel feature renaming look good. There's no crisis about which attributes need to be shared and which are copied if you just identify the right classes in the first place.
A better example of the need for multiple inheritance is a robust implementation of a new class, "Matrix". Instances of Matrix must provide their own specialized behavior for an interesting subset of arithmetic operations, and must also provide appropriate collection behavior. Thus, in a Smalltalk context, they want to be descendents of both Collection and Magnitude. In my opinion, MultipleInheritance is the most concise and robust way to model this behavior of Matrix. Once the nose of MultipleInheritance is permitted inside the tent, the rest of the camel must surely follow, leading to the need for some mechanism to address conflicts about operations and behavior among ancestors. -- TomStambaugh
Agreed, once the nose of MultipleInheritance is in the tent, you have to handle it properly. Having said that, sometimes you just have to acknowledge that you've got a "has-a" rather than an "is-a" relationship. --
EditText of this page
(last edited April 10, 2012)
or FindPage with title or text search