A pattern is a named answer to a pressure that keeps recurring. That is the whole subject, and also where it goes wrong: the names are easy to learn and the judgement is not, so most codebases hurt by patterns were hurt by someone applying a real one to a problem they did not have. Each buys something and charges for it, usually in indirection. This guide is about the charge as much as the purchase — what each family is for, what it costs, and how to tell apart shapes that differ only in intent.
Each chapter opens with the short version. Tap one to read the detail.
What a pattern is, and what it costs
~2 min
A pattern is a named solution to a recurring problem in a stated context, together with the forces it balances — not a snippet, not a library. Applied before the variation it absorbs exists it buys pure indirection, which is why more patterns does not mean better design.
Creating objects without naming the class
~2 min
Creational patterns hide which concrete classes the system uses and how instances are made. The misconception is that a factory signals maturity: with one implementation it adds a type and a jump and buys nothing, and the singleton is global mutable state with better manners.
Wrappers, and the four things a wrapper is for
~2 min
Most structural patterns wrap something, and the wrapping looks identical, so they are told apart by purpose: convert an interface, simplify one, add behaviour, or control access. Every one costs a hop per call and a frame in every stack trace.
Behaviour: who decides what happens next
~2 min
Behavioral patterns distribute the choice of what runs, so the useful question is who chooses: the caller, the object itself, or a request captured earlier. The recurring mistake is treating subscription as the whole of the observer, when teardown is half of it.
Principles: what they buy and what they charge
~2 min
The five principles — single-responsibility, open-closed, Liskov-substitution, interface-segregation and dependency-inversion — are each a bet that one axis will vary. The misconception is that an interface with one implementation is abstraction; it is indirection until a second implementation exists.
Dependency injection, and the argument it does not win
~2 min
Injection hands a collaborator in rather than letting the class look it up, and constructor injection is the default because a half-wired object then cannot exist. The misconception is that injection is what makes code testable — the source that named the pattern disagrees.
Where the business logic lives
~2 min
A procedure per request is right while logic is thin; objects carrying data and behaviour pay off once rules multiply. The misconception is that naming classes after domain nouns produces the second — it produces the mapping bill without the benefit.
Objects and rows
~2 min
Object models have collections and inheritance; tables have neither, and the persistence family exists to manage that mismatch. The misconception is that a mapper is simply the grown-up choice — on a schema that mirrors the model it is machinery with nothing to buy.
Boundaries: the wire, and edits that outlive a transaction
~2 min
The misconception is that a remote call is a slow method call. Granularity that is free in memory becomes the design across a process boundary — and once an edit spans several requests, the database transaction no longer protects it, which is why offline locking exists.
Smells and anti-patterns: signals, not verdicts
~2 min
A smell is a surface indication that usually corresponds to a deeper problem — fast to spot, and deliberately not proof. The misconception is that the list is a lint configuration. An anti-pattern is the stronger claim, and it requires a documented way out.
Refactoring: structure, without behaviour
~2 min
Refactoring changes internal structure while leaving observable behaviour alone, in a series of small steps. Two misconceptions to drop: that the word covers any large rewrite, and that replacing a conditional with polymorphism is automatically the better shape.
Modelling a domain, and the architecture-level bets
~2 min
Domain-driven design centres development on a model carrying the domain's real processes and rules, in language shared with the people who know it. The misconception is that the class stereotypes are the point — adopt them without the shared language and you have renamed some files.
Written by Keentune. We are not affiliated with or endorsed by the organizations whose documentation informs this guide, and any linked sources belong to their respective owners.
All exam, test, and product names and trademarks are the property of their respective owners and are used here for identification and reference only. Keentune is independent study practice — not affiliated with, authorized, or endorsed by any of these organizations.