25.4 TAXOMANIA

For everyone of the inheritance categories introduced later in this chapter, the heir redeclares (redefines or effects) some inherited features, or introduces features of its own, or adds to the invariant. (It may of course do several of these things.) A consequence is:

----------------------------------------------------------------------------
Taxomania rule Every heir must introduce a feature, redeclare an
inherited feature, or add an invariant clause.
----------------------------------------------------------------------------

What this rule addresses is a foible sometimes found among newcomers who have been won over to the O-O method, and over-enthusiastically start seeing taxonomical divisions everywhere (hence the name of the rule, a shortcut for "taxonomy mania"). The result is over-complicated inheritance hierarchies. Taxonomy and inheritance are meant to help us master complexity, not to introduce complexity. Adding useless classification levels is self-defeating.

As is so often the case, you can gain the proper perspective --- and bring the enthusiastic neophytes back to reason --- by keeping in mind the ADT view at all times. A class is the implementation, partial or total, of an abstract data type. Different classes, in particular a parent and an heir, should describe different ADTs. Since an ADT is entirely characterized by the applicable features and their properties (captured in the class by assertions), a new class should change an inherited feature, introduce a new feature, or change some assertion. Since preconditions and postconditions can only be changed through feature redefinition, the last case means the addition of an invariant clause (as in restriction inheritance, one of the categories in our taxonomy).

You may occasionally justify a case of taxomania --- a class that does not bring anything new of its own, apart from its existence --- on the grounds that the heir class describes an important variant of the notion described by the parent, and that you are introducing it now to pave the way for future introduction or redeclaration of features, even if none has occurred so far. This may be valid when the inheritance structure corresponds to a generally accepted classification in the problem domain. But you should always be wary of such cases, and resist the introduction of new feature-less classes unless you can find compelling arguments.

Here is an example. Assume a certain system or library includes a class PERSON and that you are considering adding heirs MALE and FEMALE. Is this justified? You will have to take a closer look. A personnel management system that includes gender-specific features, pertaining for example to maternity leave, may benefit from having heir classes MALE and FEMALE. But in many other cases the variants, if present, would have no specific features; for example statistical software that just records the gender of individuals may be better off with a single class PERSON and a boolean attribute

 female: BOOLEAN

or perhaps

 Female: INTEGER is unique;
Male: INTEGER is unique 

rather than new heirs. Yet if there is any chance that specific features will be added later on, the corresponding classification is so clearly known in the problem domain that you may prefer to introduce these heirs anyway.

One guideline to keep in mind is the Single Choice principle. We have learned to distrust the use of explicit variant lists, as implemented by unique constants, for fear of finding our software polluted with conditional instructions of the form

if gender = Female then   ...  else
...  

or inspect instructions. This is, however, not too much of a concern here:

• One of the principal criticisms against this style was that any addition of a variant would cause a chain reaction of changes throughout the software, and this example will not need new variants.
  

• Even with a fixed set of variants, the above style is much less effective than relying on dynamic binding through calls such as this_personlsome_operation where some_operation may be redeclared differently for MALE and FEMALE. But then if we do need to discriminate on a person's gender we violate the premise of this discussion --- that there are no features specific to the variants. If such features do exist, inheritance is clearly justified.
  

The last comment alerts us to the real difficulty. Simple cases of taxomania --- in which the patient needlessly adds intermediate nodes all over the inheritance structure --- are relatively easy to diagnose (by noticing classes that have no specific features) and cure. But what if the variants do have specific features, although the resulting classification conflicts with other criteria? A personnel management system for which we can justify a class FEMALE_EMPLOYEE because of a few specific features might have other distinctions as well, such as permanent versus temporary employees, or supervisory versus non-supervisory ones. Then we do not have taxomania any more; we are simply back to the problem of multi-criteria classification, for which the possible solutions are discussed later in this chapter.

PREVIOUS SECTION ---- NEXT SECTION