On methodology ntirely devoted to methodology,the next few chapersmaking up part Dofthis book-examine how to address the issues facing object-oriented projects:how to find the classes;how not to misuse inheritance;the place of object-oriented analysis; fundamental design ideas ("patterns");how to teach the method;the new software lifecycle.The result will,I hope,help you understand how best to take advantage of the techniques that we have now finished exploring. It is appropriate,before going into the study of the rules,to reflect on the role of methodology in software.This will be an opportunity to define meta-rules-rules on how to make rules-which will help us devise sound methodological advice and separate the best from the rest in the methodological literature.In passing we will devise a taxonomy ofrules,finding out that certain kinds are more desirable than others.Finally we will reflect on the attractive and dangerous role of metaphors,and take a short lesson in modesty. 19.1 SOFTWARE METHODOLOGY:WHY AND WHAT People want guidance.The quest for Principles of Truth,which one only has to follow to succeed,is neither new nor specific to software. The software literature,including for the past few years its object-oriented branch, has capitalized on this eagemess and attempted to offer recipes.This has resulted in much useful advice being made available(along with some more questionable ideas). We must remember,however,that there is no easy path to quality software.Earlier chapters have pointed out several times that software construction is a challenging task.In the past few years our grasp of the issues has vastly improved,as illustrated in particular by the techniques presented in this book,but at the same time the size and ambition of what we are try ing to do has been growing even faster,so the problem remains as difficult as it ever was It is important,then,to know the benefits and limitations of software methodology. From the following chapters and from the rest of the object-oriented literature,you are entitled to expect good advice,and the benefit of other people's experience.But neither here nor there will you find a sure-fire way to produce good software. A comparison made in an earlier chapter helps set the limits of what you can expect. In many respect,building a software system is similar to developing a mathematical theory. Mathematics,as software construction,can be taught,including the general principles that help talented students produce brilliant results;but no teaching can guarantee success.19 On methodology Entirely devoted to methodology, the next few chapters — making up part D of this book — examine how to address the issues facing object-oriented projects: how to find the classes; how not to misuse inheritance; the place of object-oriented analysis; fundamental design ideas (“patterns”); how to teach the method; the new software lifecycle. The result will, I hope, help you understand how best to take advantage of the techniques that we have now finished exploring. It is appropriate, before going into the study of the rules, to reflect on the role of methodology in software. This will be an opportunity to define meta-rules — rules on how to make rules — which will help us devise sound methodological advice and separate the best from the rest in the methodological literature. In passing we will devise a taxonomy of rules, finding out that certain kinds are more desirable than others. Finally we will reflect on the attractive and dangerous role of metaphors, and take a short lesson in modesty. 19.1 SOFTWARE METHODOLOGY: WHY AND WHAT People want guidance. The quest for Principles of Truth, which one only has to follow to succeed, is neither new nor specific to software. The software literature, including for the past few years its object-oriented branch, has capitalized on this eagerness and attempted to offer recipes. This has resulted in much useful advice being made available (along with some more questionable ideas). We must remember, however, that there is no easy path to quality software. Earlier chapters have pointed out several times that software construction is a challenging task. In the past few years our grasp of the issues has vastly improved, as illustrated in particular by the techniques presented in this book, but at the same time the size and ambition of what we are trying to do has been growing even faster, so the problem remains as difficult as it ever was. It is important, then, to know the benefits and limitations of software methodology. From the following chapters and from the rest of the object-oriented literature, you are entitled to expect good advice, and the benefit of other people’s experience. But neither here nor there will you find a sure-fire way to produce good software. A comparison made in an earlier chapter helps set the limits of what you can expect. In many respect, building a software system is similar to developing a mathematical theory. Mathematics, as software construction, can be taught, including the general principles that help talented students produce brilliant results; but no teaching can guarantee success