$22.1 STUDYING A REQUIREMENTS DOCUMENT 725 Discovery and rejection It takes two to invent anything.One makes up combinations;the other chooses, recognizes what is important to him in the mass of things which the first has imparted to him.What we call genius is much less the work of the first than the readiness of the second to choose from what has been laid before him. Paul Valery (cited in [Hadamard 1945]) Along with its straightforward lessons,this discussion has taught us a few more subtle consequences. The simple lessons have been encountered several times:do not put too much trust in a requirements document;do not put any trust in grammatical criteria. A less obvious lesson has emerged from the review of"false alarms":just as we need criteria for finding classes,we need criteria for rejecting candidate classes-concepts which initially appear promising but end up not justifying a class of their own.The design discussions of this book illustrate many such cases. “Pseudo-random To quote just one example:a discussion,yet to come,of how best to provide for pseudo- number generators: random number generation,starts naturally enough by considering the notion of random a design exercise”, number,only to dismiss it as not the appropriate data abstraction. page 754. The O-O analysis and design books that I have read include little discussion of this task.This is surprising because in the practice of advising O-O projects,especially with relatively novice teams,I have found that eliminating bad ideas is just as important as finding good ones. It may even be more important.Sit down with a group of users,developers and managers trying to get started with object technology with a fresh new project and enthusiasm fresher yet.There will be no dearth of ideas for classes (usually proposed as "objects").The problem is to dam the torrent before it damns the project.Although some class ideas will probably have been missed,many more will have to be examined and rejected.As in a large-scale police investigation,many leads come in,prompted or spontaneous;you must sort the useful ones from the canards. So we must adapt and extend the question that serves as the topic for this chapter. "How to find the classes"means two things:not just how to come up with candidate abstractions but also how to unmask the inadequate among them.These two tasks are not executed one after the other;instead,they are constantly interleaved.Like a gardener,the object-oriented designer must all the time nurture the good plants and weed out the bad: Class Elicitation principle Class elicitation is a dual process:class suggestion,class rejection. The rest of this chapter studies both components of the class elicitation process.§22.1 STUDYING A REQUIREMENTS DOCUMENT 725 Discovery and rejection It takes two to invent anything. One makes up combinations; the other chooses, recognizes what is important to him in the mass of things which the first has imparted to him. What we call genius is much less the work of the first than the readiness of the second to choose from what has been laid before him. Paul Valéry (cited in [Hadamard 1945]). Along with its straightforward lessons, this discussion has taught us a few more subtle consequences. The simple lessons have been encountered several times: do not put too much trust in a requirements document; do not put any trust in grammatical criteria. A less obvious lesson has emerged from the review of “false alarms”: just as we need criteria for finding classes, we need criteria for rejecting candidate classes — concepts which initially appear promising but end up not justifying a class of their own. The design discussions of this book illustrate many such cases. To quote just one example: a discussion, yet to come, of how best to provide for pseudo￾random number generation, starts naturally enough by considering the notion of random number, only to dismiss it as not the appropriate data abstraction. The O-O analysis and design books that I have read include little discussion of this task. This is surprising because in the practice of advising O-O projects, especially with relatively novice teams, I have found that eliminating bad ideas is just as important as finding good ones. It may even be more important. Sit down with a group of users, developers and managers trying to get started with object technology with a fresh new project and enthusiasm fresher yet. There will be no dearth of ideas for classes (usually proposed as “objects”). The problem is to dam the torrent before it damns the project. Although some class ideas will probably have been missed, many more will have to be examined and rejected. As in a large-scale police investigation, many leads come in, prompted or spontaneous; you must sort the useful ones from the canards. So we must adapt and extend the question that serves as the topic for this chapter. “How to find the classes” means two things: not just how to come up with candidate abstractions but also how to unmask the inadequate among them. These two tasks are not executed one after the other; instead, they are constantly interleaved. Like a gardener, the object-oriented designer must all the time nurture the good plants and weed out the bad: The rest of this chapter studies both components of the class elicitation process. Class Elicitation principle Class elicitation is a dual process: class suggestion, class rejection. “Pseudo-random number generators: a design exercise”, page 754