$22.2 DANGER SIGNALS 729 In other cases,you should only design the inheritance hierarchy once you have at least a first grasp of the abstractions.(The classification effort may of course lead you to revise your choice of abstractions,prompting an iterative process in which the tasks of class elicitation and inheritance structure design feed each other.)If,early in a design process,you find the participants focusing on classification issues even though the classes are not yet well understood,they are probably putting the cart before the horse. With novices,this may be a variant of the object-class confusion.I have seen people start off with inheritance hierarchies of the "SAN FRANCISCO and HOUSTON inherit from C/TY"kind-simply to model a situation where a single class,C/TY,will have several instances at run time. No-command classes Sometimes you will find a class that has no routine at all,or only provides queries(ways to access objects)but no commands (procedures to modify objects).Such a class is the equivalent of a record in Pascal or a structure in Cobol or C.It may indicate a design mistake,but the mistake may be of two kinds and you will need to probe further. First,let us examine three cases in which the class does not indicate improper design: It may represent objects obtained from the outside world,which the object-oriented software cannot change.They could be data coming from a sensor in a process- control system,packets from a packet-switching network,or C structures that the O- O system is not supposed to touch. “FACILITY INHER- Some classes are meant not for direct instantiation,but for encapsulating facilities ITANCE”,24.9page such as constants,used by other classes through inheritance.Such facility 847. inheritance will be studied in the discussion of inheritance methodology. Finally,a class may be applicative,that is to say describe non-modifiable objects; instead of commands to modify an object it will provide functions that produce new objects,usually of the same type.For example the addition operation in classes Command fimnctions INTEGER,REAL and DOUBLE follows the lead of mathematics:it does not modify were defined in“Fnc any value but,given two valuesx and y,produces a third onex+y.In the abstract tion categories",page data type specification such functions will,like others that yield commands,be 134. characterized as command functions. In all these cases the abstractions are easy to recognize,so you should have no difficulty identifying the two cases that may indeed point to a design deficiency. See"A checklist", Now for these suspicious cases.In the first one,the class is justified and would need page 770. commands;the designer has simply forgotten to provide mechanisms to modify the corresponding objects.A simple checklist technique presented in the discussion of class design will help avoid such mistakes. In the second case,most directly relevant to this discussion,the class was not justified.It is not a real data abstraction,simply some piece of passive information which might have been represented by a structure such as a list or array,or just by adding more attributes to another class.This case sometimes happens when developers write a class for§22.2 DANGER SIGNALS 729 In other cases, you should only design the inheritance hierarchy once you have at least a first grasp of the abstractions. (The classification effort may of course lead you to revise your choice of abstractions, prompting an iterative process in which the tasks of class elicitation and inheritance structure design feed each other.) If, early in a design process, you find the participants focusing on classification issues even though the classes are not yet well understood, they are probably putting the cart before the horse. With novices, this may be a variant of the object-class confusion. I have seen people start off with inheritance hierarchies of the “SAN_FRANCISCO and HOUSTON inherit from CITY ” kind — simply to model a situation where a single class, CITY, will have several instances at run time. No-command classes Sometimes you will find a class that has no routine at all, or only provides queries (ways to access objects) but no commands (procedures to modify objects). Such a class is the equivalent of a record in Pascal or a structure in Cobol or C. It may indicate a design mistake, but the mistake may be of two kinds and you will need to probe further. First, let us examine three cases in which the class does not indicate improper design: • It may represent objects obtained from the outside world, which the object-oriented software cannot change. They could be data coming from a sensor in a process￾control system, packets from a packet-switching network, or C structures that the O￾O system is not supposed to touch. • Some classes are meant not for direct instantiation, but for encapsulating facilities such as constants, used by other classes through inheritance. Such facility inheritance will be studied in the discussion of inheritance methodology. • Finally, a class may be applicative, that is to say describe non-modifiable objects; instead of commands to modify an object it will provide functions that produce new objects, usually of the same type. For example the addition operation in classes INTEGER, REAL and DOUBLE follows the lead of mathematics: it does not modify any value but, given two values x and y, produces a third one x + y. In the abstract data type specification such functions will, like others that yield commands, be characterized as command functions. In all these cases the abstractions are easy to recognize, so you should have no difficulty identifying the two cases that may indeed point to a design deficiency. Now for these suspicious cases. In the first one, the class is justified and would need commands; the designer has simply forgotten to provide mechanisms to modify the corresponding objects. A simple checklist technique presented in the discussion of class design will help avoid such mistakes. In the second case, most directly relevant to this discussion, the class was not justified. It is not a real data abstraction, simply some piece of passive information which might have been represented by a structure such as a list or array, or just by adding more attributes to another class. This case sometimes happens when developers write a class for “FACILITY INHER￾ITANCE”, 24.9, page 847. Command functions were defined in “Func￾tion categories”, page 134. See “A checklist”, page 770