T his is a book about programming in an object-oriented way and about how to use design patterns to solve commonplace problems in object-oriented systems.

I’ve based this book on the philosophy that the best way to learn and understand the design patterns is to see them in action, all jumbled up, just as they occur in the real world.

Consequently, this book presents design patterns to you by looking at computer programs. My intent is to both clarify and bring down to earth Gamma, Helm, Johnson, and Vlissides’s seminal work Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1995). (The four authors are often called the Gang of Four [or GoF], and their book is usually called the Gang-of-Four book.) The current volume puts the GoF book into context, presenting and teaching design patterns as they occur in the real world. By the time you’re done, you’ll have seen all of the Gang-of-Four patterns but in the context of real computer programs.

Don’t get me wrong—this book does not pretend to supplant the GoF book but rather to complement it. Gamma, Helm, Johnson, and Vlissides made an enormous contribution to the OO-design community with their work, and this book certainly wouldn’t exist without it. The GoF approach is abstruse and dense to many programmers, however, thus the need for the current volume.

The current book is atypical—it’s “inside out” when compared to other books on design patterns. Rather than catalog the design patterns and present unrealistically simple examples in each section of the catalog, this book describes two computer programs in terms of the design patterns they use. You see how the patterns appear in real programs and how the patterns interact with one another in complex ways.

The splendid isolation of a catalog-of-design-patterns approach (such as the original Design Patterns) simply doesn’t permit this real-world understanding. The catalog is great if you’ve already worked on code that demonstrates the pattern. If you don’t have prior experience with such code, however, the catalog approach is impenetrable. Also, catalogs can leave you with a good intellectual understanding of the patterns but with almost no understanding of how to actually use the patterns to produce real code.

Prerequisites

I’m assuming that you know Java and have written at least a few programs in it. In particular, I use anonymous inner classes a lot, so you’ll have to be solid on that syntax. You also need to be familiar with the “core” Java packages such as java.io and the basics of the user-interface subsystems (Swing and AWT). This is all stuff you probably got when you learned the language.

I’m also assuming that you know the basics of object-oriented programming: inheritance, interfaces, polymorphism, and so on. Later in the book I’ll talk about things such as the downside of extends, but to make sense of these discussions, you’ll have to know what extends does. I assume that you already know the upside, so I won’t bore you with a treatise on what OO-language features such as inheritance are good for. Don’t interpret a discussion of the negative side of an idiom or language feature as indicating that there is no positive side to that idiom or feature. I’m just assuming that you don’t need to be told something you already know.

Finally, I assume a nodding familiarity with UML, the “Unified” Modeling Language—a graphical design notation useful for showing, among other things, the static (class) structure of a program and how the objects that comprise the program interact at runtime.

Should you need to come up to speed before you continue, I’ve listed references for all these topics on the web page discussed in the section “Resources and References.” You can probably muddle through the UML without much formal understanding of the subject. Without Java, though, you’ll be completely lost.

Assumptions

I assume throughout this book that you want to know how to build solid object-oriented solutions, so I don’t qualify every statement that I make with that assumption. Often, reasonable procedural alternatives exist to OO strategies, but I don’t discuss these alternatives.

What I mean to accomplish by mentioning this obvious, I hope, point is to head off the inevitable critics who will complain that the entire book is invalid simply because it doesn’t explicitly discuss every alternative to every problem, including the hard-core procedural alternatives.

Examples of topics that I know will set off the banshees include implementation encapsulation (which implies that the most common use of get/set functions should be assiduously avoided) and the overuse of implementation inheritance (which creates unnecessary coupling relationships).

Warning! Warning! Will Robinson!

Finally, I also want to warn you about me.

If you haven’t figured it out by now, I have opinions and intend to express them, and I don’t usually qualify my statements with apologies. If you don’t like that, buy a different book.

Everyone has opinions, and hiding those opinions under a veneer of impartiality accomplishes nothing but obfuscation. You’re welcome to disagree with me, but please disagree because you have a strong argument to support your beliefs. “Nobody does it that way” is not a strong argument. Neither is its converse: “Everybody does it.”

I’m sometimes accused of being “dogmatic.” If by “dogmatic” you mean that I defend ideas forcefully when I find that those ideas work well in real code (and conversely disparage ideas that fail miserably in practice), then I guess I am dogmatic. I think of my attitude as pragmatic, though, not dogmatic. I’m hard-nosed about following OO principles, because every time I’ve violated those principles, I’ve had to rewrite the code. I just don’t have time to do things twice.

My practical bias is reflected in the structure of this book, building it around code rather than an academic taxonomy. It may annoy you when, in the interest of making something easy to understand to a programmer, I loosen up the language a bit. This is a book for programmers, though, not for theoreticians. (I find it odd that I’m also sometimes accused of being “academic,” as if that’s a pejorative. The real academics usually don’t like my work because it’s not sufficiently formal and relies too heavily on code rather than mathematics.)

I also allow myself occasional digressions into relevant design topics rather than staying strictly focused on the patterns. I’m assuming that you need to know why I do things, not just what I’m doing. I’m writing as if we are sitting around a table talking, not as if I’m standing at a podium giving a formal lecture. If you want formality, I refer you to the Gang-of-Four Design Patterns book. It’s an excellent book that presents this material in a highly structured fashion that will be more to your taste.

Resources and References

Rather than augment this book with a “Resources” section that will be out-of-date before the book hits the streets, I’ve built a Design-patterns resources web page at http://www.holub.com/goodies/patterns/. You’ll find links to all the code in this book on that page, and you’ll also find things such as reading lists and links to other patterns-related sites on the web.

Further!

So now that you’ve been warned, it’s time to get to work. Design patterns (and thinking in a design-patterns way) are wonderful things. They can help you work more effectively, they can make your code vastly easier to maintain, and they can provide you with a vocabulary that will make communication with other programmers and designers much more effective. This book shows you how design patterns really work and how to use them to write excellent code.