Can you name a Design Pattern?

A Design Pattern? You mean from the ’90s?

Yes, they were made popular in 1995. Though they are much older than that.

There was a book wasn’t there?

Yes, it was named Design Patterns: Elements of Reusable Object-Oriented Software.

Written by four guys.

Correct, “The Gang of Four”: Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides.[1]

It’s kind of old and out of date now, isn’t it?

What makes you say that?

Well, there are newer books.

Indeed there are many newer books on the topic, and some are quite good; but none are quite so impactful and insightful as the original.

Anyway, the whole idea is old and broken.

Broken?

Yeah, like, I’ve heard people say that Design Patterns were invented to fix some problems in Object-Oriented Programming.

Some problems? What problems?

I dunno. That’s just what I’ve heard. Like, Design Patterns were really just workarounds for bad languages.

Bad Languages? Like what?

I Dunno – like, maybe C++ and Java. You know. Static languages.

What a strange thing to say. Smalltalk, a dynamic language, played a significant role.

Well, and anyway, they don’t really apply to the future, with Functional Programming and all?

My Goodness! What Nonsense!

Well, that’s just what I’ve heard.

I think you’ve been listening to the wrong people.

It was just twitter and facebook and stuff.

Ah, I see. Social Networks: The font of all wisdom and knowledge.

Yeah, OK, I get your point.

I hope so; but just in case let me be perfectly clear…

That’s what politicians say when they’re about to lie to you.

… (sigh)…Listen … Carefully. The Design Patterns book is one of the most important books, if not THE most important book, written about software within the last 20 years.

Oh, come on now. It’s twenty years old. I mean maybe it was great way back in the nineteen hundreds; but this is like the twenty-first century. We’ve got Ruby. We’ve got Clojure. We’ve got Node, and Angular, and Rails and IOS and Mobile and … I mean … Software’s changed a lot! We’ve outgrown all that old stuff.

You think software has changed in the last 20 years?

Well, of course! I mean… Duh.

You have much to learn about what the word “Change” means. In fact, the fundamentals of software have changed very little in the last four decades.

How can you say that? I mean, look at all this new stuff!

You mean the glitter?

Glitter!! Are you calling Rails, and Angular, and Node and… Glitter?

Yes. Glitter. It sparkles for awhile but it doesn’t last. There’s always more glitter to follow.

But there are some really great ideas in those frameworks. How can you call that glitter?

The ideas aren’t glitter. The frameworks are. Most of the ideas in those frameworks are old. They’ve been around for decades. The ideas are … Design Patterns.

Wait. Are you saying that Active Record is a Design Pattern?

Of course it is. Or rather there are several Design Patterns within Active Record. Active Record is a unique combination of many very old, tried and true, patterns of software design.

OK, now hold on. Just what is a design pattern?

A Design Pattern is a named canonical form for a combination of software structures and procedures that have proven to be useful over the years.

Named? Canonical? Huh?

Yes, every Design Pattern has a name and a canonical form. Professional software designers use those names and forms to communicate with each other. When they see the name of a pattern in software, or if they recognize the form, then they immediately know the designer’s intent.

Can you give me an example?

Sure, here are two that are not from the Design Patterns book. Model-View-Controller and Dependency-Injection.

Those are Design Patterns?

Of course. They have a well-recognized name, and they have a canonical form.

I get the name part; but what’s the form?

Well, take MVC. You’d expect there to be three objects, a model object, a controller object, and a view object. The Model handles the business rules. The Controller handles input. The View handles output.

And I put the models, views, and controllers in different directories.

Uh, well, Yes! In certain frameworks that has become part of the canonical form.

What do you mean in certain frameworks.

Just that in the original specification of MVC, directories weren’t mentioned. Indeed, the original form of MVC is considerably more involved than what I just described; but that’s a story for a different time.

You mean there’s more to MVC than just three directories and three types of objects?

(chuckle) Oh, yes. Much, much, more. But that’s for later.

OK, so I’m starting to get the idea. If I say “Dependency Injection”, everybody knows exactly what I mean. So I don’t have to explain myself.

Right. It saves a lot of time when designers all know the Design Patterns. They can just talk to each other using those names.

OK, and if follow the form of the pattern, then everybody will know what to expect in the code.

Right! By following the canonical form, you relieve everyone else of the work of having to decode what you have done. They recognize the form and can follow it easily.

And you say there are a lot of these patterns?

The Design Patterns book gives names and forms to twenty-three tried and true solutions to common software problems.

Hmmm. And they’re all as useful as MVC and DI?

Some are much more useful than that!

Hmmm. I should probably learn them then.

I would say so! Can you name one now?

Uh…

Just one.

Uh…

Let me help you: Abstract Factory, Builder, Factory Method, Prototype, Singleton, Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy, Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, and Visitor.

I think I’ve got some studying to do.

Yes, I think you do.

[1] John Matthew Vlissides passed away on the 24th of November, 2005. He was a colleague and a friend. He came to my aid more than once. He is missed.