$22.2 DANGER SIGNALS 727 and display of characters...";"NSTextStorage is a semi-concrete subclass of NSMutableAttributedString that manages a set of client NSLayoutManagers,notifying them of any changes...".Even if (as is most likely the case here)the classes discussed represent valuable data abstractions,it would be preferable to describe them less operationally by emphasizing these abstractions. Imperative names Assume that in a tentative design you find a class name such as PARSE or PRINT-a verb in the imperative or infinitive.It should catch your attention,as signaling again a probable case of a class that "does one thing",and should not be a class. Occasionally you may find that the class is right.Then its name is wrong.This is an “absolute positive'”rule: Class Name rule A class name must always be either: A noun,possibly qualified. .(Only for a deferred class describing a structural property)an adjective. Although like any other one pertaining to style this rule is partly a matter of convention,it helps enforce the principle that every class represents a data abstraction The first form,nouns,covers the vast majority of cases.A noun may be used by itself,as in TREE,or with some qualifying words,as in LINKED LIST,qualified by an adjective,and LINE DELETION,qualified by another noun. “Structure inherit-- The second case,adjectives,arises only for a specific case:structural property ance",page 831. classes describing an abstract structural property,as with the Kernel Library class COMPARABLE describing objects on which a certain order relation is available.Such classes should be deferred;their names (in English or French)will often end with ABLE. They are meant to be used through inheritance to indicate that all instances of a class have a certain property;for example in a system for keeping track of tennis rankings class PLAYER might inherit from COMPARABLE.In the taxonomy of inheritance kinds,this scheme will be classified as structure inheritance. See chapter 21. The only case that may seem to suggest an exception to the rule is command classes, as introduced in the undo-redo design pattern to cover action abstractions.But even then you should stick to the rule:call a text editor's command classes LINE DELETION and WORD CHANGE,not DELETE LINE and REPLACE WORD. English leaves you more flexibility in the application of this rule than many other languages,since its grammatical categories are more an article of faith than an observation of fact,and almost every verb can be nouned.If you use English as the basis for the names in your software it is fair to take advantage of this flexibility to devise shorter and simpler names:you may call a class IMPORT where other languages might treat the equivalent as a verb only,forcing you to use nouns such as IMPORTATION.But do not cheat:class§22.2 DANGER SIGNALS 727 and display of characters…”; “NSTextStorage is a semi-concrete subclass of NSMutableAttributedString that manages a set of client NSLayoutManagers, notifying them of any changes…”. Even if (as is most likely the case here) the classes discussed represent valuable data abstractions, it would be preferable to describe them less operationally by emphasizing these abstractions. Imperative names Assume that in a tentative design you find a class name such as PARSE or PRINT — a verb in the imperative or infinitive. It should catch your attention, as signaling again a probable case of a class that “does one thing”, and should not be a class. Occasionally you may find that the class is right. Then its name is wrong. This is an “absolute positive” rule: Although like any other one pertaining to style this rule is partly a matter of convention, it helps enforce the principle that every class represents a data abstraction The first form, nouns, covers the vast majority of cases. A noun may be used by itself, as in TREE, or with some qualifying words, as in LINKED_LIST, qualified by an adjective, and LINE_DELETION, qualified by another noun. The second case, adjectives, arises only for a specific case: structural property classes describing an abstract structural property, as with the Kernel Library class COMPARABLE describing objects on which a certain order relation is available. Such classes should be deferred; their names (in English or French) will often end with ABLE. They are meant to be used through inheritance to indicate that all instances of a class have a certain property; for example in a system for keeping track of tennis rankings class PLAYER might inherit from COMPARABLE. In the taxonomy of inheritance kinds, this scheme will be classified as structure inheritance. The only case that may seem to suggest an exception to the rule is command classes, as introduced in the undo-redo design pattern to cover action abstractions. But even then you should stick to the rule: call a text editor’s command classes LINE_DELETION and WORD_CHANGE, not DELETE_LINE and REPLACE_WORD. English leaves you more flexibility in the application of this rule than many other languages, since its grammatical categories are more an article of faith than an observation of fact, and almost every verb can be nouned. If you use English as the basis for the names in your software it is fair to take advantage of this flexibility to devise shorter and simpler names: you may call a class IMPORT where other languages might treat the equivalent as a verb only, forcing you to use nouns such as IMPORTATION. But do not cheat: class Class Name rule A class name must always be either: • A noun, possibly qualified. • (Only for a deferred class describing a structural property) an adjective. “Structure inherit￾ance”, page 831. See chapter 21