"You say you want some evolution. Well, you know, I'm just doing what I can."
-- Charles Darwin, On the Origin of Species

People who 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 people working in OO -- 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.

I'm not yet an OO programmer. Will this book teach me an OO 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++?

I've 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 getting in the way of the examples. I'd like you to feel welcome in this book whatever your programming language might be.

However, there is a fragment of Java in this book. I used Java because it's more accessible to a non-Java programmer than C++ is to a non-C++ programmer. 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 the other object-oriented books on the market. 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 stuff!

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 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 OO 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 the 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 the UML for depicting classes, along with their attributes and operations. Chapter 4 covers UML for hierarchies of subclasses and superclasses, associations, and aggregate and composite objects. 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-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 form the central pillar of Part III, using the concepts of state-space and behavior to assess when a class hierarchy is both sound and extendible. 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 explains design techniques such as mix-in classes and operation rings that will improve class reusability and maintainability. Chapter 14 rounds off the book by taking 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.

Chapter 15 traces the development of an object-oriented component for a business application. In following the component's construction, 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 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 everyth