Design Patterns

Patterns are named, recurring solutions. Their real value is vocabulary: "let's make that a Strategy" communicates a whole design in three words.

Creational. Factory Method defers which concrete class to instantiate. Builder constructs complex objects step by step, which beats a constructor with nine optional parameters. Singleton guarantees one instance — and is the most criticised pattern in the catalogue, because it is global mutable state that also makes testing hard, since you cannot substitute it.

Structural. Adapter wraps an interface you cannot change into one your code expects — the pattern behind almost every third-party integration. Decorator adds behaviour by wrapping rather than subclassing, so you can compose logging, caching, and retry independently. Facade puts a simple interface in front of a complicated subsystem.

Behavioural. Strategy makes an algorithm swappable at runtime, and is the standard answer to a long conditional selecting between behaviours. Observer lets objects subscribe to events rather than being called directly — the shape underneath every event emitter. Template Method fixes the skeleton of an algorithm and lets subclasses fill in steps. Command turns a request into an object, which is what makes undo and queuing possible.

Two more you meet constantly outside the original catalogue. Repository abstracts data access behind a collection-like interface, so business logic does not know about SQL. Dependency Injection passes collaborators in rather than constructing them internally, which is what makes a class testable at all.

The failure mode is pattern-hunting. Patterns are for recognising a problem you already have. Applying them speculatively produces indirection with no benefit — an AbstractFactoryStrategyBuilder for something that should have been a function.