I have been organizing books I read before. This one is Design Patterns Explained.
The original is Design Patterns Explained, by Alan Shalloway and James Trott.
I got into design patterns through the Refactoring.Guru website and Head First Design Patterns. Back then I thought that once I'd read through the patterns and knew what each one did, I basically knew how to use them. Factory, Observer, Singleton, Strategy — I could name them all.
But when it came to actually building something, I was still lost. I knew a pattern existed, but I didn't know when to reach for it, or how to map it onto the problem in front of me. Knowing a list of patterns and knowing how to use them are two very different things, with a big gap in between.
That gap is what Design Patterns Explained filled for me. It doesn't hand you a catalog; it takes the way of thinking apart and shows it to you. The whole book walks you through designing a real piece of software — the example is a CAD/CAM system for sheet-metal parts. It doesn't tell you "use a Factory here." It lets you watch how the author's mind moves, step by step, when he hits the problem.
Memorizing patterns and thinking in patterns sound alike, but they're worlds apart. One is remembering the answer. The other is learning how to arrive at it.
There's one passage I still remember. The author was stuck on that CAD/CAM design — the standard object-oriented approach just wouldn't come together. So he gave up, got up, and went for a walk. About thirty steps in, it suddenly clicked. The first time I read it, I thought it was just a feel-good story. Later I understood what he was really saying: a pattern isn't an answer you drop in, it's a direction for your thinking. It helps you ask the right question.
In the book he breaks "thinking in patterns" into a few steps. First, find the pattern. Then analyze and apply it — which itself splits into adjusting to the business needs, choosing the right pattern, finding the key point, and re-evaluating. Only at the end do you add value. Notice that not one of those steps is "recall the pattern from memory." Every step is a conversation with the problem itself.
So how do you have that conversation? The book's core move is called commonality-variability analysis. It sounds academic, but it's plain enough: separate the parts of the problem that don't change from the parts that do. In the CAD/CAM example, the commonality is "the CAD/CAM system," the variation is V1 and V2; the commonality is "the part," the variation is slots, holes, square cuts, special shapes.
Once you split commonality from variation, the design almost surfaces on its own. The unchanging parts become interfaces; the changing parts each get their own implementation. Look back and you'll see this is just dependency inversion — and it's exactly what an Abstract Factory does. But you didn't start from Abstract Factory and go looking for a place to use it. You thought the problem through first, and then noticed, "oh, this shape happens to be a pattern."
Patterns are the result, not the starting point.
There's another table in the book that I find clearer than the sheet-metal example. Say you're building an e-commerce system: first you sell in the US, then Canada, then Germany. The author doesn't rush to write code. He draws a table first: each row is a thing you have to do — calculate shipping, validate the address, calculate tax, currency, date format; each column is a market — US, Canada, Germany. Then you fill it in, cell by cell.
As you fill it in, everything that varies gets forced out into the open. Shipping: UPS in the US, FedEx in Canada, a local carrier in Germany. Tax: state tax in the US, GST/PST in Canada, VAT in Germany. Dates: mm/dd in the US, dd/mm in Germany.
What I find most interesting are actually the blanks. Germany's column has a "max weight 30 kg," and the US and Canada cells are empty. A blank doesn't necessarily mean there's nothing there — more likely the customer just never mentioned it. The author says that at this point, instead of asking the customer "is there anything else," you're better off asking directly, "do you have a weight limit?" A specific question is what gets you a real answer.
So what is this table doing? It's helping you round up everything that varies, all at once. You have to round them up first before you can even talk about whether to encapsulate them, or how. What I only understood later is that the starting point of thinking in patterns isn't a pattern — it's seeing the problem clearly.
Another example really resonated with me. A team has to support the systems of many partner companies. The core rules are roughly the same, but every partner is a little bit different. So the code starts sprouting piles of if-then-else, or worse, whole sections get copy-pasted and tweaked in a few spots. I've walked both roads. Too many ifs and you get what the author calls branching proliferation; copy-paste and you end up with changes to make everywhere and things you miss everywhere.
The third road the book offers is Template Method. Find the common process across these cases, pull the common part out, and abstract away the differences. It's still the same move: separate what stays from what changes. Reading this, I realized the book, from every angle, is really talking about one thing — encapsulating variation. And that's something you can't get from memorizing patterns.
What memorizing patterns gets you even less is this: a real design rarely uses just one pattern. That CAD/CAM solution ends up weaving several together — Abstract Factory, Bridge, Facade, Adapter. Bridge holds up the skeleton, Abstract Factory produces whole families of objects, Facade wraps the old V1 system behind one clean entry point, Adapter adapts the V2 interface to fit. None of them is the star; they work together.
The author also mentions something I found neat: patterns give each other clues. Recognize one, and the next often surfaces on its own. So the hard part was never remembering the 23 patterns. It's being able to see how many points of variation are hiding in a problem, and which patterns to bring in together to contain them.
This way of thinking is, if anything, more interesting now. Because the parts with a fixed way of writing them — the ones that follow a known idiom — can largely be handed to AI. You want a thread-safe singleton, AI writes it for you; you want to turn a pile of ifs into a Strategy pattern, AI can refactor it. That kind of thing, AI remembers better than I do.
So do I still need to memorize patterns? After this book, my answer is clear: what you memorize was never the implementation, it's the judgment behind it. Whether the thing that varies here should be encapsulated; whether this common process should be pulled into a Template; whether these two concepts should be separated by an interface. AI can't make those calls for you, because it doesn't know where your system is going to change next. Only you know that, and only when you're in conversation with the problem.
That's why I think this book is Old School and yet hasn't aged a day. What it teaches isn't 23 answers. It's how, when you hit a new problem, to take it apart, ask the right question, and find the point that varies.
Memorizing patterns is walking a road someone else already walked. Thinking in patterns is being able to walk a new one yourself. AI can pave the road for you, but where to go still comes down to whether you can read the terrain.