"You say you want some evolution. Well, you know, I'm doing what I can."
-- Charles Darwin, On the Origin of Species
reviewed this book in its draft form had several questions for me, questions that
perhaps you share. Let me address some of them.
I'm a programmer.
Why should I care about design?
Everyone who writes code also
designs code -- either well or badly, either consciously or unconsciously. My
goal in writing this book is to encourage O.O. professionals -- and their number
increases annually -- 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 one another.
Will this book teach me an O.O. programming language?
No. Although I occasionally swoop down close to code, this isn't
a book on object-oriented programming.
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.
Why aren't the code examples in this book in C++?
written the code in this book in a language of my own devising, which is a blend
of four popular languages: C++, Eiffel, Java, and Smalltalk. I did this because
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 the language's
arcane syntax distracting. Some examples are given in Java because it's more accessible
to a non-Java programmer than C++ is to a non-C++ programmer. I'd like you to
feel welcome in this book whatever your programming language might be.
Why isn't this book devoted to the design of windows, icons, and menus?
There 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. However, in Chapter 7, I offer some notation for window-navigation design.
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
So, 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.
You've 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 software construct in which operations (which are like functions or procedures)
are organized around a set of variables (which are like data). A class implements
a type that defines the group of objects belonging to that class.
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 and
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 to 7) covers Unified Modeling Language
(UML), which has become the de facto standard notation for depicting object-oriented
design. In passing, Part II also illustrates many of the structures that you find
in object-oriented systems. Chapter 3 introduces UML for depicting classes, along
with their attributes and operations. Chapter 4 covers UML for associations, aggregate
and composite objects, and hierarchies of subclasses and superclasses. Chapter
5 sets out UML for messages (both sequential and asynchronous), while Chapter
6 covers UML for state diagrams. Chapter 7 reviews UML for system architecture
and the windows that form a human interface.
Part III (Chapters 8 to 14)
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. Chapters 10 and 11 are the central pillars of Part
III, applying the concepts of state-space and behavior to assess when a class
hierarchy is both sound and extendable.
Chapter 12 offers some light relief,
as it examines designs taken from real projects, including both the subtle and
the absurd. (Chapter 12 is really about the dangers of abusing inheritance and
polymorphism.) Chapter 13 looks at some ways of organizing operations within a
given class, and it explains design techniques, such as mix-in classes and operation
rings, that will improve class reusability and maintainability.
14 takes a stab at the old question: "What makes a good class?" In answering
this question, Chapter 14 describes the various kinds of class interface, ranging
from the horrid to the sublime. A class with an exemplary interface will be a
worthy implementation of an abstract data-type. If the class also obeys the fundamental
principles laid out in earlier chapters, then it will be as robust, reliable,
extensible, reusable, and maintainable as a class can ever be.
15 rounds off the book by examining the characteristics, together with the advantages
and disadvantages, of software components. In tracing the development of an object-oriented
component for a business application, I recall some of the object-oriented principles
of the previous chapters.
Although 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 misleading.
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
writing 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.
offer courses on object-oriented design?
Yes. My firm, Wayland
Systems, offers several courses on object-oriented topics. Our curriculum continually
changes, so check out www.waysys.com for our latest offerings.
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
But, whatever your role in life, I hope that you enjoy this
book and find it useful. Good luck!