Patterns Meta & Practice

A design pattern is a language-neutral solution shape for a recurring design problem, like Observer or Strategy. An idiom is a small, language-specific way of writing something well, like C++ RAII or Python comprehensions. Patterns travel between languages; idioms usually do not.

It means you don't pick patterns before writing code. You write the simplest thing that works, and when the code starts to smell (duplication, a growing conditional), you refactor in small behavior-preserving steps until a known pattern emerges. The smell justifies the pattern.

Start from the concrete problem: what varies, what must stay stable, what change you expect. Then look for a pattern whose stated intent restates that problem. Choosing a pattern first and bending code to fit it adds complexity without solving anything.

Because a singleton is global mutable state with a static access point. Callers reach it directly instead of declaring it, so dependencies are hidden, tests share and leak state between each other, substitution for fakes is hard, and lifetime/threading rules become implicit.

Design patterns organise a few classes or functions inside a module (Strategy, Observer, Decorator). Architectural patterns organise whole systems — modules, processes, services (layered, hexagonal, event-driven, microservices). Design patterns are cheap to change; architectural ones are expensive and constrain deployment and teams.

Both start from big if/switch chains. Use Strategy when the branches are interchangeable ways to compute the same thing chosen by the caller or config. Use State when the branches depend on an object's current mode and the branches also decide the next mode.

By intent, not shape. Strategy swaps interchangeable algorithms chosen from outside. State encapsulates behaviour that changes with an object's lifecycle stage, and states decide the next state. Command turns a request into an object you can queue, log, retry, or undo.

Strategy, Command, Template Method hooks, simple Factories and much of Observer collapse: instead of an interface plus an implementing class, you pass a function or lambda. The intent survives — varying behaviour is still injected — but the ceremony (extra types, boilerplate) disappears.

A pattern buys cheap change along one axis and charges indirection everywhere. Weigh how likely that change is, how many new types and hops you add, whether coupling direction improves, and whether tests get simpler. If you cannot name the change it makes cheap, skip it.

Premature abstraction is adding interfaces, factories or configuration for requirements you only imagine. YAGNI — "You Aren't Gonna Need It" — says don't build it until a real need exists, because guessed abstractions usually fit the wrong axis and still cost reading and change effort.

The problem stays the same — traverse a collection without exposing its internals. What changes is the cost: instead of hand-writing an iterator class with hasNext/next, you write a generator or comprehension. Writing the class version anyway is unidiomatic and adds state and bugs.

It targets sibling subclasses whose methods do the same steps in the same order but differ in a few step bodies. You make the steps identical in shape, pull the shared sequence up into the superclass as one method, and leave the differing steps as overridable hooks.

By what the wrapper does to the interface and the behaviour. Adapter changes the interface to one the client expects. Decorator keeps the same interface and adds behaviour, stackably. Proxy keeps the same interface and controls access (lazy, remote, caching, permission). Facade offers a simpler interface over a whole subsystem.

With a service locator, a class calls a shared registry to fetch what it needs, so its dependencies are hidden inside method bodies. With dependency injection, they arrive through the constructor, so they are visible, required at construction, and easy to replace in tests.

They are five language idioms serving one shared intent: release a resource on every exit path, including errors. The intent — scope-bound resource management — is the portable idea; RAII, try-with-resources, using, defer and with-statements are how each language spells it.

Apply it when a class's core job is buried under optional extras controlled by flags — logging, caching, compression, discounts. You extract each extra into a wrapper class that implements the same interface, delegates to the wrapped object, and adds its bit. Callers compose only the extras they need.

It means removing a pattern that costs more than it gives — for example a Strategy interface with one implementation or an unnecessary Singleton. You inline the indirection step by step, with tests green, until the simpler direct code remains.

Don't rewrite it. Pin current behavior with characterization tests, find seams where responsibilities cluster, extract one cohesive piece at a time behind a delegating façade, route new work to the extracted parts, and add guardrails so the old class cannot regrow.

Judge by consequences in context, not by name. An anti-pattern is a common solution whose costs reliably outweigh its benefits and for which a better alternative exists. If you can't state the concrete harm here and a cheaper alternative, it's just an unfamiliar choice.

Partly true: some patterns exist only because a language lacked a feature (Strategy without first-class functions, Visitor without pattern matching) and vanish once it gains one. But patterns also name problems and trade-offs, which no feature removes. Treat them as shared vocabulary, not code templates.

Decide by reversibility and blast radius. Decisions you can change later inside one codebase (class structure) should emerge from refactoring. Decisions that are expensive to undo — data models, public contracts, service boundaries, security — deserve up-front design. Teams need tests and a norm that abstractions must be earned and can be removed.

Combine patterns when each answers a different question — for example a factory choosing a strategy, or a composite of commands. It is a warning sign when several patterns solve the same question, when wiring code outweighs domain code, or when nobody can describe the runtime object graph.