who reviewed this book in its draft form had several questions for me, questions
that perhaps you share. Let me address some of them.
Why does the
title say every programmer? Surely you exaggerate.
there are two kinds of programmers: those writing object-oriented code right now
and those who'll be writing object-oriented code soon. Everyone who writes code
also designs code -- either well or badly, either consciously or unconsciously.
My goal in writing this book is to encourage people to create good object-oriented
designs consciously and prior to coding. To this end, I introduce notation, principles,
and terminology that you and your colleagues can use to evaluate your designs
and to discuss them meaningfully with each other.
Will this book
teach me an object-oriented programming language?
I occasionally swoop down close to code, this isn't a book on object-oriented
But if I'm learning an object-oriented language, will
this book help? Yes, it will.
If you don't currently know an object-oriented
programming language, you can begin your object-oriented knowledge with Chapter
1. Knowing the key concepts of object orientation will speed your learning an
object-oriented language and, I hope, boost your morale as you move into unfamiliar
territory. The later chapters of the book, on sound design, will also help you
in getting your early programs to work successfully.
On the other hand,
if you're already an experienced object-oriented programmer, you can use Parts
II and III of the book to enhance the design skills that are vital to your being
a rounded, professional software designer or programmer.
the code examples in this book in C++?
I've written the code in
this book in a language of my own devising, which is a blend of three popular
languages: C++, Eiffel, and Smalltalk. I did this because -- guess what! -- there
are two kinds of programmers: those who are fluent in C++ and those who aren't.
If you're a C++ aficionado, then you'll find the code a breeze to translate into
C++. If you're not familiar with C++, then you might have found that language's
arcane syntax getting in the way of the examples. I'd like you to feel welcome
in this book whatever your programming language might be.
this book devoted to the design of windows, icons, and menus?
are two reasons: First, I don't believe that object orientation is useful only
for the design of graphical user interfaces. Second, there are many books on the
market devoted solely to the topic of object-oriented window design. I want this
book to cover topics that are not well covered by other object-oriented books.
Is this book about a methodology?
No. As you know, a development
methodology contains much more than design. For example, there's requirements
analysis, library management, and so on. Also, a true methodology needs to explain
how the various development activities fit together. A lot of stuff!
instead of turning out a book as diffuse as many other books on object orientation,
I decided to focus on a single topic: object-oriented design.
said a lot about what this book isn't about. What is it about?
It's about the fundamental ideas, notation, terminology, criteria, and principles
of object-oriented software design. Object-oriented software is software that
comprises objects and the classes to which they belong. An object is a component
in which methods (which are like functions or procedures) are organized around
a set of variables (which are like data). A class implements a type defining the
group of objects that belong to that class.
The above modest sentences
hold some surprising implications for software designers and programmers, implications
that arise from the design concepts of inheritance, polymorphism, and second-order
design. But, since you asked a specific question, let me give you a specific answer.
Part I of the book (Chapters 1-2) provides an introduction to object orientation.
Chapter 1 summarizes the key concepts and demystifies "polymorphism,"
"genericity," and all the other O.O. jargon. Chapter 2 sets object orientation
into the framework of previous developments in software. If you're already familiar
with object orientation (perhaps by having programmed in an object-oriented language),
then you can skip or skim Part I.
Part II (Chapters 3-7) covers object-oriented
design notation and, in passing, illustrates many of the structures that you find
in object-oriented systems. Chapter 3 introduces notation for depicting classes,
along with their external and internal designs. Chapter 4 covers notation for
hierarchies of subclasses and superclasses and notation for aggregate objects.
Chapter 5 sets out notation for messages (both synchronous and asynchronous),
while Chapter 6 discusses object-oriented modifications to traditional state-transition
diagrams. Chapter 7 ties up loose ends, by covering notation for object persistence,
system architecture, and the windows that form a human interface.
III (Chapters 8-12) covers object-oriented design principles in some depth. Chapter
8 sets the scene with the crucial notions of connascence and level-2 encapsulation.
Chapter 9 explores the various domains that "classes come from" and
describes different degrees of class cohesion. Chapter 10, the central pillar
of Part III, uses the concepts of state-space and behavior to assess when a class
hierarchy is both sound and extendable.
Chapter 11 offers some light relief,
as it examines designs taken from real projects, including both the subtle and
the absurd. (Chapter 11 is really about the dangers of abusing inheritance and
polymorphism.) Chapter 12 rounds off the book by taking a stab at the old question,
What makes a good class? In answering this question, Chapter 12 describes the
various kinds of class interface -- ranging from the seemly to the horrid -- and
explains design techniques such as mix-in classes and method rings, that you can
use to make your classes as robust and as maintainable as possible.
I've added plenty of examples, diagrams, and exercises to reinforce what I say
in the main text, I must admit that the material in Part III gets tough at times.
Nevertheless, I decided not to trivialize or dilute important issues. Some aspects
of object-oriented design are difficult and to suggest otherwise would be to patronize
you. Anyway, I know you can take it!
Does this book cover everything
in object-oriented design?
I very much doubt it. Each day, I
learn more about object orientation -- and I'm sure you do, too. Indeed, it would
be a dull world if a single book could tell us everything about object-oriented
design and leave us with nothing more to learn. And not everything in this book
may be completely true! I certainly changed my mind about one or two things after
I wrote my previous books, as I became older and wiser -- well, older, anyway.
So, although I think that I've covered many important design principles in this
book, if you're serious about object orientation you should continue to read as
much as you can and always challenge what you read. And, please, do your best
to refine the ideas that I've presented here.
Bottom-line, as they
say: Is this book for me?
What kind of question is that? You expect
me to say, "No!"? But seriously, folks, this book's for you if you are
-- or are about to become -- a programmer, designer, systems engineer, or technical
manager on a project using object-oriented techniques. Even if you're a beginner
to object orientation, you can glean a lot from this book by reading Part I, practicing
some object-oriented programming, and then returning to Parts II and III. You
should also read this book if you're a university student or professional programmer
who has mastered the techniques of standard procedural programming and is looking
for wider horizons. Much of the book's material is suitable for a final-year computer-science
or software-engineering course in object orientation. But, whatever your role
in life, I hope that you enjoy this book and find it useful. Good luck!