22 Iow to find the classes oremost among the goals of object-oriented methodology,since the structure of O-O software is based on decomposition into classes,is that it should give us some advice on how to find these classes.Such is the purpose of the following pages.(In some of the literature you will see the problem referred to as"finding the objects",but by now we know better:what is at stake in our software architectures is not individual objects,but object types-classes. At first we should not expect too much.Finding classes is the central decision in building an object-oriented software system;as in any creative discipline,making such decisions right takes talent and experience,not to mention luck.Expecting to obtain infallible recipes for finding the classes is as unrealistic as would be,for an aspiring mathematician,expecting to obtain recipes for inventing interesting theories and proving their theorems.Although both activities-software construction and theory construction -can benefit from general advice and the example of successful predecessors,both also require creativity of the kind that cannot fully be covered by mechanical rules.If(like many people in the industry)you still find it hard to compare the software developer to a mathematician,just think of other forms of engineering design:although it is possible to provide basic guidelines,no teachable step-by-step rules can guarantee good design of buildings or airplanes. In software too,no book advice can replace your know-how and ingenuity.The principal role of a methodological discussion is to indicate some good ideas,draw your attention to some illuminating precedents,and alert you to some known pitfalls. This would be true with any other software design method.In the case of object technology,the observation is tempered by some good news,coming to us in the form of reuse.Because much of the necessary invention may already have been done,you can build on others'accomplishments. There is more good news.By starting with humble expectations but studying carefully what works and also what does not,we will be able,little by little and against all odds,to devise what in the end deserves to be called a method for finding the classes.One of the key steps will be the realization that,as always in design,a selection technique is defined by two components:what to consider,and what to reject.22 How to find the classes Foremost among the goals of object-oriented methodology, since the structure of O-O software is based on decomposition into classes, is that it should give us some advice on how to find these classes. Such is the purpose of the following pages. (In some of the literature you will see the problem referred to as “finding the objects”, but by now we know better: what is at stake in our software architectures is not individual objects, but object types — classes.) At first we should not expect too much. Finding classes is the central decision in building an object-oriented software system; as in any creative discipline, making such decisions right takes talent and experience, not to mention luck. Expecting to obtain infallible recipes for finding the classes is as unrealistic as would be, for an aspiring mathematician, expecting to obtain recipes for inventing interesting theories and proving their theorems. Although both activities — software construction and theory construction — can benefit from general advice and the example of successful predecessors, both also require creativity of the kind that cannot fully be covered by mechanical rules. If (like many people in the industry) you still find it hard to compare the software developer to a mathematician, just think of other forms of engineering design: although it is possible to provide basic guidelines, no teachable step-by-step rules can guarantee good design of buildings or airplanes. In software too, no book advice can replace your know-how and ingenuity. The principal role of a methodological discussion is to indicate some good ideas, draw your attention to some illuminating precedents, and alert you to some known pitfalls. This would be true with any other software design method. In the case of object technology, the observation is tempered by some good news, coming to us in the form of reuse. Because much of the necessary invention may already have been done, you can build on others’ accomplishments. There is more good news. By starting with humble expectations but studying carefully what works and also what does not, we will be able, little by little and against all odds, to devise what in the end deserves to be called a method for finding the classes. One of the key steps will be the realization that, as always in design, a selection technique is defined by two components: what to consider, and what to reject