ntirely devoted to methodology, the next few chapters — making up part
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
, and take a short lesson in modesty.
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.