Gang of Four Patterns

I’m about to give a talk on Gang of Four patterns.  I’ve got to admit, I’d rather have been talking about the seminal post-punk band.  For one thing, if people disagree with my opinions (“Entertainment” is genius, for the record…) they’re unlikely to take it personally.  The thing is, everyone treats the book as being something akin to the Bible in the 16th century:

• It’s incredibly important
• It’s full of useful ideas
• It’s hugely respected
• But no-one’s read it
• And a fair number of those that do don’t understand it, and take it out context.

None of these are actually problems with the book per se, but misinterpretation is annoyingly common.  You hear people boasting of how many different patterns they managed to implement in their code base, as if increased complexity were something of which to be proud.  You see people shoehorning patterns into problems which don’t match the use cases.  Personally, I wish more people bothered to read Chapter 1, especially the section on favouring composition over inheritance.

Taking Another Look

I have to admit, these attitudes coloured my own stance on the book for years.  I was leery of developers who espoused patterns because it seemed that use of patterns was more important to them than delivering solutions.  I’m hardly the first person to say this. 

Like the Bible, it’s better when you have a modern translation, since frankly 15 years is a long time in software development.  To give you an idea, Java was released a year later.  Some were a stupid idea, some just aren’t as important anymore, some are special cases of more general ideas, some people use all the time and the only real benefit is terminology.  And some…

…well actually, some are so important that you really, really, need to understand them.  So, I decided to write a skeptic’s guide to design patterns.  You’re almost certainly going to disagree with me, but for the record, the patterns I think are still relevant and unobvious today are:

• Factory / Abstract Factory
• Command
• Chain of Responsibility
• State

Sorry, that’s it.  Don’t worry, I’m wearing asbestos.

Initial Observations

Going through the book again, a couple of themes keep cropping up:

• Unlike most modern patterns, the use cases often overlap.  Because the focus is on low-level programming constructs, there’s often more than one way to do something.
• The design patterns are, contrary to popular belief, extremely language dependent.  Iterator is irrelevant in C#, Visitor is irrelevant in JavaScript.
• The patterns are often special cases of more general concepts and techniques.

You’re not going to find any diagrams in this stuff.  Frankly, I think that UML is a positive hindrance to understanding what’s going on in most of these patterns.

• For one, I don’t regard the presence or absence of an abstract interface as fundamentally changing a design, it’s just a refinement (one that you should pretty much always be using).
• For another, the difference between composition and inheritance is significant, but I’d argue doesn’t actually change a pattern.  Hence, I’d argue that Template and Strategy are actually the same.