726 HOW TO FIND THE CLASSES $22.2 22.2 DANGER SIGNALS To guide our search it is preferable to start with the rejection part.It will provide us with a checklist of typical pitfalls,alert us to the most important criteria,and help us keep our search for good classes focused on the most productive efforts. Let us review a few signs that usually indicate a bad choice of class.Because design "f is not a completely formalized discipline,you should not treat these signs as proofof a bad rules".page 666. design;in each case one can think of some circumstances that may make the original decision legitimate.So what we will see is not,in the terms of a previous chapter, "absolute negatives"(sure-fire rules for rejecting a design)but "advisory negatives": danger signals that alert you to the presence of a suspicious pattern,and should prompt you to investigate further.Although in most cases they should lead you to revise the design,you may occasionally decide in the end that it is right as it stands The grand mistake Many of the danger signals discussed below point to the most common and most damaging mistake,which is also the most obvious:designing a class that isn't. The principle of object-oriented software construction is to build modules around object types,not functions.This is the key to the reusability and extendibility benefits of the approach.But beginners will often fall into the most obvious pitfall:calling "class" something which is in fact a routine.Writing a module as class...feature...end does not make it a true class;it may just be a routine in disguise. This Grand Mistake is easy to avoid once you are conscious of the risk.The remedy is the usual one:make sure that each class corresponds to a meaningful data abstraction. What follows is a set of typical traits alerting you to the risk that a module which presents itself as a candidate class,and has the syntactical trappings of a class,may be an illegal immigrant not deserving to be granted citizenship in the O-O society of modules. My class performs... In a design meeting,an architecture review,or simply an informal discussion with a developer,you ask about the role of a certain class.The answer:"This class prints the results”or“this class parses the inpui”,or some other variant of“This class does.”. The answer usually points to a design flaw.A class is not supposed to do one thing but to offer a number of services(features)on objects of a certain type.If it really does just one thing,it is probably a case of the Grand Mistake:devising a class for what should just be a routine of some other class. Perhaps the mistake is not in the class itself but in the way it is being described,using phraseology that is too operational.But you had better check. In recent years the"my class does..."style has become widespread.A NeXT document NeXT documenta- describes classes as follows:"The NSTextView class declares the programmatic interface tion for OpenStep, to objects that display text laid out.."An NSLayoutManager coordinates the layout pre-release 4.0.726 HOW TO FIND THE CLASSES §22.2 22.2 DANGER SIGNALS To guide our search it is preferable to start with the rejection part. It will provide us with a checklist of typical pitfalls, alert us to the most important criteria, and help us keep our search for good classes focused on the most productive efforts. Let us review a few signs that usually indicate a bad choice of class. Because design is not a completely formalized discipline, you should not treat these signs as proof of a bad design; in each case one can think of some circumstances that may make the original decision legitimate. So what we will see is not, in the terms of a previous chapter, “absolute negatives” (sure-fire rules for rejecting a design) but “advisory negatives”: danger signals that alert you to the presence of a suspicious pattern, and should prompt you to investigate further. Although in most cases they should lead you to revise the design, you may occasionally decide in the end that it is right as it stands. The grand mistake Many of the danger signals discussed below point to the most common and most damaging mistake, which is also the most obvious: designing a class that isn’t. The principle of object-oriented software construction is to build modules around object types, not functions. This is the key to the reusability and extendibility benefits of the approach. But beginners will often fall into the most obvious pitfall: calling “class” something which is in fact a routine. Writing a module as class… feature … end does not make it a true class; it may just be a routine in disguise. This Grand Mistake is easy to avoid once you are conscious of the risk. The remedy is the usual one: make sure that each class corresponds to a meaningful data abstraction. What follows is a set of typical traits alerting you to the risk that a module which presents itself as a candidate class, and has the syntactical trappings of a class, may be an illegal immigrant not deserving to be granted citizenship in the O-O society of modules. My class performs… In a design meeting, an architecture review, or simply an informal discussion with a developer, you ask about the role of a certain class. The answer: “This class prints the results” or “this class parses the input”, or some other variant of “This class does…”. The answer usually points to a design flaw. A class is not supposed to do one thing but to offer a number of services (features) on objects of a certain type. If it really does just one thing, it is probably a case of the Grand Mistake: devising a class for what should just be a routine of some other class. Perhaps the mistake is not in the class itself but in the way it is being described, using phraseology that is too operational. But you had better check. In recent years the “my class does…” style has become widespread. A NeXT document describes classes as follows: “The NSTextView class declares the programmatic interface to objects that display text laid out…”; “An NSLayoutManager coordinates the layout “A typology of rules”, page 666. NeXT documenta￾tion for OpenStep, pre-release 4.0