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 never stops to announce "use a Factory here." You watch how the author's mind moves, step by step, when he hits the problem.
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 is more like a direction for your thinking, one that 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 the order runs the other way: 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.
The table has one job: rounding up everything that varies, all at once. Once you have the full list, there's something to talk about.
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.
And real design has another layer of trouble: it 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. The hard part is seeing 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. That judgment is the part AI can't do 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. The 23 patterns are just the catalog; what it actually teaches is how, when you hit a new problem, to take it apart and ask the right question.
AI can pave the road for you, but where to go still comes down to whether you can read the terrain.