Hey there! Let me rant for a minute.

Then. Remember back in the day how we learned? A tutorial, a broken build, a search, a Stack Overflow answer from 2014 that almost worked, a Udemy or Pluralsight course, and finally, at some ungodly hour, a fix you actually understood.

That cycle, repeated for years, is what turned us into software engineers. Not the tools. The cycle.

Now. Everything is “just ask AI”. Rename a variable? Ask AI. Write a commit message? Ask AI. Push your changes to your repository? Ask AI. Explain the code you wrote yesterday? Ask AI. And when it works, nobody asks why. And when it breaks, nobody knows why.

And it’s all fine, right up until you hit your token limit. Then the vibe is dead. Haha. No answers, no momentum, and a codebase you can’t explain because you never really built it.

Here’s the uncomfortable truth. Today, anyone can be a developer, and honestly, that’s amazing. But being able to generate a build doesn’t mean you can deliver a quality one. Somewhere along the way, a lot of people got lazy, and the fundamentals got left behind.

The hype doesn’t help either. There’s so much noise around AI right now that people just see the AI. They don’t see the years of experience behind the screen: the engineer who knows the output is wrong before running it, who knows which test will prove it, who knows why that clean-looking refactor just broke checkout.

That’s what the cycle gave us. And that’s the one thing AI can’t hand you.


Tools Evolve. Fundamentals Remain.

So I decided to put that to the test, using one of the most fundamental books in our field: Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, better known as the Gang of Four.

The result is a public repository that shows all 23 patterns in action. And yes, I built it with an AI agent.

The agent wrote most of the code. But it couldn’t decide what a realistic mess looks like, which pattern belongs to which problem, what “done” means, or how to prove a refactor didn’t break anything. That part came from the cycle. The agent was fast. The fundamentals are what made it right.

This series is my homage to those fundamentals, and to the four people who wrote them down.


Agenda:

  1. Why Another Design Patterns Series?
  2. Meet the Repository
  3. How Each Post Works
  4. The Series Map
  5. How to Follow Along

Why Another Design Patterns Series?

Back in 2023, I wrote Discovering Design Patterns, a high-level tour of the catalogue. It covered the what. This series covers the why and the how, with real code you can clone, run and break.

And there’s a reason for that. Most design pattern examples look something like this: a Shape class, a Circle and a Square, maybe a Duck that quacks. They explain the structure well enough, but they skip the most important part.

The problem.

Patterns are answers. They only make sense once you’ve felt the question. Nobody reaches for a Strategy because they woke up wanting an interface. They reach for it because a switch statement grew a fifth case and something broke in production.

So this series flips the usual order. Every post starts with code that hurts, and only then introduces the pattern that fixes it.

Meet the Repository

Everything in this series is backed by gang-of-four-in-action, built in C# on .NET 10. It has three parts:

  1. The baseline. A fictional online store called CornerStore. It works correctly, but it’s deliberately messy, with 23 catalogued code smells. Think of it as the codebase you inherit on day one of a new engagement.
  2. 23 pattern solutions. Each one is a full copy of the baseline that fixes exactly one smell with one pattern. Everything else stays untouched, so you can compare before and after without unrelated noise.
  3. The capstone. All 23 patterns applied to a single copy, so you can see how they work together.

My favourite part: every solution produces the exact same output as the baseline. The store runs a scripted trading day, and a test compares its transcript line by line with the approved one. If a refactor changes behaviour, the build fails. The patterns change the shape of the code, never what it does.

That one test is also what made it safe to let an AI agent do the heavy lifting. I didn’t have to trust that it got things right. The build proved it, every single time.

How Each Post Works

Each pattern post follows the same rhythm:

  • The scene. A moment in CornerStore where the code gets in the way.
  • The smell. The actual baseline code, and why it hurts.
  • The idea. The pattern in plain words, with an everyday analogy.
  • The refactor. Before and after, plus a diagram.
  • What it cost. Every pattern adds something. We count it.
  • When not to use it. Because patterns are not free.
  • Easily confused with. The pattern’s closest look-alike.
  • Try it yourself. A link straight to the code.

The posts tell the story. The README in each folder of the repository is the reference: participant tables, sequence diagrams and run commands.

The Series Map

I’m following the book’s order within each category. That’s the homage, and it also matches the previous and next links in the repository.

Group Posts
Start here Introduction · Meet CornerStore
Creational Abstract Factory · Builder · Factory Method · Prototype · Singleton
Structural Adapter · Bridge · Composite · Decorator · Facade · Flyweight · Proxy
Behavioral Chain of Responsibility · Command · Interpreter · Iterator · Mediator · Memento · Observer · State · Strategy · Template Method · Visitor
Putting it together Commonly Confused Patterns · The Capstone
Behind the scenes Built with Microsoft HVE Core

A quick refresher on the three categories:

  • Creational patterns deal with how objects get created.
  • Structural patterns deal with how objects are composed into larger structures.
  • Behavioral patterns deal with how objects talk to each other and share responsibility.

Curious how the AI and the fundamentals actually worked together? Jump straight to Built with Microsoft HVE Core. It covers the briefs, the guardrails, and the moments where the process caught mistakes that I’d never have spotted by reading code.

How to Follow Along

You’ll need the .NET 10 SDK and Git. Then:

git clone https://github.com/vaughnellis/gang-of-four-in-action.git
cd gang-of-four-in-action
dotnet restore GangOfFour.slnx
dotnet build GangOfFour.slnx --no-restore -c Release
dotnet test GangOfFour.slnx --no-build -c Release

To watch CornerStore run its trading day:

dotnet run --project baseline/src/CornerStore/CornerStore.csproj -- scenarios/trading-day.json

The links in this series point to the v1.0.0 release, so the code you see in a post is always the code that was there when it was written.

My suggested path:

  1. Start with Meet CornerStore. Every pattern post builds on it.
  2. Work through the categories in order, or jump to the pattern you’re curious about. Each post stands on its own.
  3. Finish with Commonly Confused Patterns and The Capstone.

One last thing: the intents and explanations in this series are my own words, not the book’s. If this series gets you hooked, do yourself a favour and grab a copy of the original. More than thirty years on, it still holds up.

Because tools evolve. Fundamentals remain.

As always, if you have any comments, suggestions, or feedback, I’d love to hear from you!

Happy Coding!

Next: Meet CornerStore