The Design Patterns Companion

Introduction From the Author

Design patterns were originally delineated in the seminal work of the Gang of Four: Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. They, in turn, were responding to an earlier work by the architect Christopher Alexander, The Timeless Way of Building. The Gang of Four's work, Design Patterns: Elements of Reusable Object-Oriented Software, received a lot of attention when it was originally published in 1994.

Some have suggested, however, that the industry has moved beyond the patterns in the more than two decades that have passed since its publication, and that in the age of agile processes and test-driven development, the patterns are no longer relevant. They say that patterns represent an old view, namely big design up front.

I disagree. Not only do I think the patterns are relevant today, I believe they are far more relevant than they were when the work was originally published. Here's why:

Patterns form a rich language of design. This is all the more important now that nearly all software projects are highly collaborative. We need reliable ways to communicate and make group decisions. Nearly all complex human activity involves specialized language: medicine, law, engineering, etc. They all have their own rich nomenclature to describe what is being proposed, or what has been done.

Patterns all follow the principles of good design in different ways. This means they are highly changeable without decay. The agile movement says, among other things, that we must embrace change. The patterns help us to do this.

This book is not meant to teach you the patterns; see the References section for books that do. This is meant to be a field guide for those who are already pattern practitioners, something to refer to as part of your day-to-day activities.

What Design Patterns Represent

The Design Patterns movement, begun (in software) by the Gang of Four (GoF) (Gamma, Helm, Johnson, & Vlissides, 1994), essentially elevated certain design elements as valuable, repeated, and high-quality examples of a particular approach to design.

Their general advice was given in three parts:

Design to interfaces.

Favor composition over inheritance.

Encapsulate the concept that varies.

All patterns adhere to this rubric in different ways. But they also all exhibit certain qualities of design, and they all adhere to a set of shared principles. What I will outline in the following pages are the three bits of guidance listed above, as well as how each pattern respects:

Strong cohesion

Proper coupling

Robust encapsulation

Avoiding redundancy

Testability

In addition, I will submit that each pattern follows good principles in design, such as open-closed, the separation of concerns, and others.

I'll start with the definitions, then examine the patterns.

Design to Interfaces

Behavior in object-oriented systems is a reflection of the interaction of objects. If you change the objects or alter their interactions, the resulting behavior changes.

This means that objects have relationships to other objects, usually through references that are used to call methods. The GoF recommends that these relationships are defined based on how the objects look to each other, not by how the objects are implemented.

It's easy to misinterpret this to mean every object should have a separate interface, referring to the type interface that many languages provide. But the advice was not meant to indicate any language-specific idiom.

An interface means any defined means of communication. A method signature is an interface; the collective public methods of a class are an interface; an abstract class is an interface; etc. What is meant by that is the interface of any interaction should be based on what is needed by the clients and not the way the behavior is implemented. Changing the implementation should not affect the interface, and thus should not affect the clients.

In other words, the full version of this is design to interfaces (how you work with them) rather than implementations (what each actually does).

Favor Composition Over Inheritance

Composition/aggregation indicates a has-a relationship between objects. Inheritance, on the other hand, indicates an is-a relationship. The GoF would seem to be suggesting that you lean toward (favor) the former rather than