Design Patterns: What? Who? When?

Have you heard of a “design pattern”? If you have, and if you know the history, and if you don’t feel like double- or triple-checking how well I’m going to explain this, you can skip this entire post. Otherwise, buckle up!

Simply put, a “design pattern” is a general, reusable solution to a commonly occurring problem. If you haven’t heard of the actual term before, you’ve almost definitely heard of some big-name, great patterns. I’m talking about stuff like:

• Builder
• Decorator
• Observer
• Command
• Singleton

Y’know, those things that pop up all over. I bet you’ve used at least one of these before.

The idea of a design pattern came out of architect Christopher Alexander’s work, culminating in the book A Pattern Language. Now, you’re probably not an architect, but you probably know some of these patterns, too. Or can at least appreciate some. Consider these while you think of places you’ve been.

Ceiling Height Variety

A building in which the ceiling heights are all the same is virtually incapable of making people comfortable.

In some fashion, low ceilings make for intimacy, high ceilings for formality. In older buildings which allowed the ceiling heights to vary, this was almost taken for granted.

Pools of Light

Uniform illumination—the sweetheart of the lighting engineers—serves no useful purpose whatsoever. In fact, it destroys the social nature of space, and makes people feel disoriented and unbounded.

Intimacy Gradient

Unless the spaces in a building are arranged in a sequence which corresponds to their degrees of privateness, the visits made by strangers, friends, guests, clients and family will always be a little awkward.

The concept got picked up by some software people (variously described as “programmers”, “developers”, “engineers”, and sometimes even “architects”), and eventually resulted in the book Design Patterns: Elements of Reusable Object-Oriented Software, which goes to show that computer people have never been good at naming. This is where those patterns I mentioned at the start came from. (Uh, and more as well. These folks didn’t write a whole book describing just five patterns.)

Design patterns apply in particular contexts, and much like any other building blocks, they can be different sizes — or to put it another way, they have different levels of detail and uses. The foundational patterns that come from the Design Patterns book are important in daily development, but other people have gone on to create or describe further patterns that apply in particular contexts. You may hardly ever run into these contexts, but you’ll be glad to know someone else thought of them before you had to.

A notable example here is Martin Fowler, who has done invaluable work in this area. His first book, Analysis Patterns, describes patterns all the way from the small and specific like Quantity (a combined number and unit, common in many current applications as Money) and Range (hey, this is even provided for you in Ruby as a core concept) to the larger and more involved, like how to model roles and organization structures.

Several years later, Fowler put out another book with several co-authors, called Patterns of Enterprise Application Architecture (the naming continues to be disappointing, doesn’t it? This is usually called PoEAA, which isn’t necessarily better, but at least it’s shorter). I started this post with a short list of well-known patterns that should be familiar to you from the very start of the software design pattern movement. Now, take a look at this PoEAA catalog and see how many of those names are familiar to you, especially if you’ve done anything with Rails.

If you’re looking for a team to help you discover the right thing to build and help you build it, get in touch.