The design patterns resource I keep sending people

#design-patterns#Docs

When someone asks me about design patterns, I usually send them to Refactoring.Guru. Here's a quick guide to what you'll find there and when it helps.

What are design patterns?

Design patterns are proven solutions to problems that come up again and again in software design. They aren't code you copy and paste. They're more like blueprints that you adapt to your own situation. Used well, they make code easier to maintain, extend, and talk about with other people.

Patterns come from real projects. The 1994 book Design Patterns by the "Gang of Four" described 23 classic patterns, and most resources since then, including Refactoring.Guru, build on it.

What's on Refactoring.Guru

The site covers 22 of those 23 patterns, in three groups:

  1. Creational patterns are about how objects get created: Factory Method, Abstract Factory, Builder, Prototype, and Singleton.
  2. Structural patterns are about how classes and objects fit together into larger structures: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, and Proxy.
  3. Behavioral patterns are about how objects work together and share responsibilities: Chain of Responsibility, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, and Visitor.

The one it leaves out is Interpreter, which most people rarely need.

Each pattern page explains the problem it solves, shows its structure in a diagram, gives example code, and lists its pros and cons and when to use it. The writing is plain and easy to follow.

When are patterns useful?

  • When a problem keeps coming back. If you keep solving the same kind of design problem, like adding new behavior without changing existing code, a pattern may fit.
  • When you're talking with your team. Patterns give everyone shared names. Saying "let's use a Strategy here" explains a whole design in a few words.
  • When you want a starting point. A pattern gives you a structure and its trade-offs, so you don't have to work everything out from scratch.

You don't have to use patterns. Use one when it clearly makes the code clearer or more flexible, and don't force one where a simple solution works.

Why I recommend Refactoring.Guru

Every pattern follows the same format, with diagrams, the problem it solves, its trade-offs, and code examples in many languages, including TypeScript, Swift, Kotlin, and others. That makes it easy to understand the idea first and then apply it in your own stack.

The site also has a free section on refactoring that goes well with the patterns. If you want to go further, its paid ebook also covers the SOLID principles.