728 HOW TO FIND THE CLASSES $22.2 IMPORT should cover the abstraction"objects being imported"(nominal),not,except for a command class,the act of importing(verbal) It is interesting to contrast the Class Name rule with the discussion of the"underline the nouns"advice at the beginning of this chapter."Underline the nouns"applied a formal grammatical criterion to an informal natural-language text,the requirements document; this is bound to be of dubious value.The Class Name rule,on the other hand,applies the same criterion to a formal text-the software. Single-routine classes A typical symptom of the Grand Mistake is an effective class that contains only one exported routine,possibly calling a few non-exported ones.The class is probably just a glorified subroutine-a unit of functional rather than object-oriented decomposition. A possible exception arises for objects that legitimately represent abstracted actions,See"Smallclasses" for example a command in an interactive system,or what in a non-O-O approach would page 714. have been represented by a routine passed as argument to another routine.But the examples given in an earlier discussion show clearly enough that even in such cases there will usually be several applicable features.We noted that a mathematical software object representing a function to be integrated will not just have the feature item (a:REAL):REAL,giving the value of the function at point a:others may include domain of definition,minimum and maximum over a certain interval,derivative.Even if a class does not yet have all these features,checking that it would make sense to add them later will reinforce your conviction that you are dealing with a genuine object abstraction. In applying the single-routine rule,you should consider all the features of a class: See“TAXOMA- those introduced in the class itself,and those which it inherits from its parents.It is not NMA”24.4,page necessarily wrong for a class text to declare only one exported routine,if this is simply an 820. addition to a meaningful abstraction defined by its ancestors.It may,however,point to a case of taxomania,an inheritance-related disease which will be studied as part of the methodology of inheritance. Premature classification The mention of taxomania suggests a warning about another common mistake ofnovices: starting to worry about the inheritance hierarchy too early in the process. As inheritance is central in the object-oriented method,so is a good inheritance structure-more accurately,a good modular structure,including both inheritance and client relations-essential to the quality of a design.But inheritance is only relevant as a relation among well-understood abstractions.When you are still looking for the abstractions,it is too early to devise the inheritance hierarchy. The only clear exception arises when you are dealing with an application domain for which a pre-existing taxonomy is widely accepted,as in some branches of science.Then the corresponding abstractions will emerge together with their inheritance structure. (Before accepting the taxonomy as the basis for your software's structure,do check that it is indeed well recognized and stable,not just someone's view of things.728 HOW TO FIND THE CLASSES §22.2 IMPORT should cover the abstraction “objects being imported” (nominal), not, except for a command class, the act of importing (verbal). It is interesting to contrast the Class Name rule with the discussion of the “underline the nouns” advice at the beginning of this chapter. “Underline the nouns” applied a formal grammatical criterion to an informal natural-language text, the requirements document; this is bound to be of dubious value. The Class Name rule, on the other hand, applies the same criterion to a formal text — the software. Single-routine classes A typical symptom of the Grand Mistake is an effective class that contains only one exported routine, possibly calling a few non-exported ones. The class is probably just a glorified subroutine — a unit of functional rather than object-oriented decomposition. A possible exception arises for objects that legitimately represent abstracted actions, for example a command in an interactive system, or what in a non-O-O approach would have been represented by a routine passed as argument to another routine. But the examples given in an earlier discussion show clearly enough that even in such cases there will usually be several applicable features. We noted that a mathematical software object representing a function to be integrated will not just have the feature item (a: REAL): REAL, giving the value of the function at point a: others may include domain of definition, minimum and maximum over a certain interval, derivative. Even if a class does not yet have all these features, checking that it would make sense to add them later will reinforce your conviction that you are dealing with a genuine object abstraction. In applying the single-routine rule, you should consider all the features of a class: those introduced in the class itself, and those which it inherits from its parents. It is not necessarily wrong for a class text to declare only one exported routine, if this is simply an addition to a meaningful abstraction defined by its ancestors. It may, however, point to a case of taxomania, an inheritance-related disease which will be studied as part of the methodology of inheritance. Premature classification The mention of taxomania suggests a warning about another common mistake of novices: starting to worry about the inheritance hierarchy too early in the process. As inheritance is central in the object-oriented method, so is a good inheritance structure — more accurately, a good modular structure, including both inheritance and client relations — essential to the quality of a design. But inheritance is only relevant as a relation among well-understood abstractions. When you are still looking for the abstractions, it is too early to devise the inheritance hierarchy. The only clear exception arises when you are dealing with an application domain for which a pre-existing taxonomy is widely accepted, as in some branches of science. Then the corresponding abstractions will emerge together with their inheritance structure. (Before accepting the taxonomy as the basis for your software’s structure, do check that it is indeed well recognized and stable, not just someone’s view of things.) See “Small classes”, page 714. See “TAXOMA￾NIA”, 24.4, page 820