Topic hub
Design Patterns
SOLID, the 23 classic design patterns and the modern ones frameworks are built on, explained simply with runnable Python, TypeScript, Java and PHP examples, plus the interview questions and a quiz.
Lessons
- Dependency Injection Without a Framework · Design Patterns, Explained Simply
Pass an object its collaborators instead of letting it create them. You get testable code with no container, no annotations and no magic. - Program to Interfaces, Favour Composition · Design Patterns, Explained Simply
The two ideas behind almost every pattern: depend on what an object can do, not what class it is, and build behaviour by combining objects instead of deep inheritance trees. - SOLID, Part 2: Liskov, Interface Segregation, Dependency Inversion · Design Patterns, Explained Simply
The L, I and D of SOLID: subclasses must keep their parent's promises, interfaces should stay small, and high-level code should depend on abstractions. - SOLID, Part 1: Single Responsibility and Open/Closed · Design Patterns, Explained Simply
The S and O of SOLID: give each class one reason to change, and add new behaviour by adding code rather than editing working code. - What a Design Pattern Is (and Isn't) · Design Patterns, Explained Simply
Patterns are named, reusable answers to design problems that keep coming back. Learn what one contains, the three families, and why the name matters as much as the code. - Builder · Design Patterns, Explained Simply
Assemble a complex object step by step with readable, named steps and one final validation, instead of a constructor with ten positional arguments. - Factory Method · Design Patterns, Explained Simply
Let subclasses decide which concrete object to create, so the code that uses the object never names its class. - Singleton (and Why It's Often an Anti-Pattern) · Design Patterns, Explained Simply
Guarantee one instance with global access. Learn how it works, why it makes code hard to test, and the usually better alternative: create one instance and pass it in. - Adapter · Design Patterns, Explained Simply
Make a class with the wrong interface work where your code expects another, by wrapping it in a small translator. - Decorator · Design Patterns, Explained Simply
Add behaviour to an object, such as logging, caching or retries, by wrapping it in objects with the same interface. Stack the wrappers in any combination without subclassing. - Observer · Design Patterns, Explained Simply
Let an object announce events to any number of subscribers, without knowing who they are or what they do, so new reactions can be added without touching the source. - State · Design Patterns, Explained Simply
Let an object change its behaviour when its internal state changes by moving each state's rules into its own class, instead of a switch statement in every method. - Strategy · Design Patterns, Explained Simply
Define a family of interchangeable algorithms behind one interface and choose one at runtime, so the code that uses them never needs an if/else to pick. - Choosing the Right Pattern · Design Patterns, Explained Simply
A practical cheat sheet: start from the symptom in your code, find the matching pattern, and tell the look-alike patterns apart. - Repository and Unit of Work · Design Patterns, Explained Simply
Hide data access behind a collection-like interface, and group changes so they are saved together in one transaction.
Decision guides
- API Gateway vs BFF vs Service Mesh
- Build vs Buy vs Open Source
- Rewrite vs Incremental Refactor vs Strangler Fig