$22.3 GENERAL HEURISTICS FOR FINDING CLASSES 731 There is a clearly associated abstraction,which can be described as a data abstraction (or as an abstract machine). The class name is a noun or adjective,adequately characterizing the abstraction. The class represents a set of possible run-time objects,its instances.(Some classes are meant to have only one instance during an execution;that is acceptable too.) Several queries are available to find out properties of an instance. Several commands are available to change the state of an instance.(In some cases, there are no commands but instead functions producing other objects of the same type,as with the operations on integers;that is acceptable too.) Abstract properties can be stated,informally or(preferably)formally,describing: how the results of the various queries relate to each other (this will yield the invariant);under what conditions features are applicable (preconditions);how command execution affects query results(postconditions) This list describes a set of informal goals,not a strict rule.A legitimate class may have only some of the properties listed.Most of the examples that play an important role in this book-from LIST and OUEUE to BUFFER,ACCOUNT,COMMAND,STATE. INTEGER,FIGURE,POLYGON and many others-have them all. 22.3 GENERAL HEURISTICS FOR FINDING CLASSES Let us now turn to the positive part ofour discussion:practical heuristics for finding classes. Class categories We may first note that there are three broad categories of classes:analysis classes,design classes and implementation classes.The division is neither absolute nor rigorous (for example one could find arguments to support attaching a deferred class L/S7 to any one of the three categories),but it is convenient as a general guideline. An analysis class describes a data abstraction directly drawn from the model of the external system.PLANE in a traffic control system,PARAGRAPH in a document processing system,PART in an inventory control system are typical examples An implementation class describes a data abstraction introduced for the internal needs of the algorithms in the software,such as LINKED LIST or ARRAY. In-between,a design class describes an architectural choice.Examples included COMMAND in the solution to the undo-redo problem,and STATE in the solution to the problem of panel-driven systems.Like implementation classes,design classes belong to the solution space,whereas analysis classes belong to the problem space.But like analysis classes and unlike implementation classes they describe high-level concepts. As we study how to obtain classes in these three categories,we will find that design classes are the most difficult to identify,because they require the kind of architectural§22.3 GENERAL HEURISTICS FOR FINDING CLASSES 731 • There is a clearly associated abstraction, which can be described as a data abstraction (or as an abstract machine). • The class name is a noun or adjective, adequately characterizing the abstraction. • The class represents a set of possible run-time objects, its instances. (Some classes are meant to have only one instance during an execution; that is acceptable too.) • Several queries are available to find out properties of an instance. • Several commands are available to change the state of an instance. (In some cases, there are no commands but instead functions producing other objects of the same type, as with the operations on integers; that is acceptable too.) • Abstract properties can be stated, informally or (preferably) formally, describing: how the results of the various queries relate to each other (this will yield the invariant); under what conditions features are applicable (preconditions); how command execution affects query results (postconditions). This list describes a set of informal goals, not a strict rule. A legitimate class may have only some of the properties listed. Most of the examples that play an important role in this book — from LIST and QUEUE to BUFFER, ACCOUNT, COMMAND, STATE, INTEGER, FIGURE, POLYGON and many others — have them all. 22.3 GENERAL HEURISTICS FOR FINDING CLASSES Let us now turn to the positive part of our discussion: practical heuristics for finding classes. Class categories We may first note that there are three broad categories of classes: analysis classes, design classes and implementation classes. The division is neither absolute nor rigorous (for example one could find arguments to support attaching a deferred class LIST to any one of the three categories), but it is convenient as a general guideline. An analysis class describes a data abstraction directly drawn from the model of the external system. PLANE in a traffic control system, PARAGRAPH in a document processing system, PART in an inventory control system are typical examples. An implementation class describes a data abstraction introduced for the internal needs of the algorithms in the software, such as LINKED_LIST or ARRAY. In-between, a design class describes an architectural choice. Examples included COMMAND in the solution to the undo-redo problem, and STATE in the solution to the problem of panel-driven systems. Like implementation classes, design classes belong to the solution space, whereas analysis classes belong to the problem space. But like analysis classes and unlike implementation classes they describe high-level concepts. As we study how to obtain classes in these three categories, we will find that design classes are the most difficult to identify, because they require the kind of architectural