Don't Panic: Design Patterns

A design pattern is a name for a recurring software problem and an arrangement that has helped contain it. It is not a box of finished code, although it is frequently found near boxes of finished code looking guilty by association. The point is to adapt roles and relationships to the system in front of you.

Software keeps changing its mind. A pricing rule gains another policy. A useful component arrives with an incompatible interface. Optional behavior starts accumulating around one service. Without a boundary, those changes tend to collect in the same class or conditional until it becomes a small museum of former decisions.

The first useful question is about variation: what changes independently while the rest should remain stable? A pattern gives that variation an owner. Strategy puts interchangeable behavior behind one contract. Adapter translates an interface at a boundary. Decorator preserves an interface while wrappers add responsibilities. Factory Method separates a creation choice from the code that uses the created object.

The surprising part is that similar shapes do not mean similar jobs. Adapter and Decorator both wrap objects, but one changes the interface a client sees while the other keeps it. Strategy and State can both delegate work, but Strategy represents a selected policy and State represents behavior tied to current state and transitions. The diagram is therefore a clue, not a verdict. Software has produced enough arrows already.

Every pattern asks for payment. It may add indirection, more objects, selection logic, or lifecycle rules. Observer separates a provider from subscribers, then requires decisions about subscription lifetime, notification order, failure handling, and reentrancy. A factory that hides one stable constructor is not prudent. It is a corridor with one door.

Start with the direct design. Describe stable behavior, identify variation, assign ownership, and compare one relevant pattern by intent and consequences. Test the smallest implementation, then revisit it after a real change. If the promised variation disappears, remove the boundary. Patterns improve design conversations when they expose a trade, not when they turn vocabulary into furniture.

Read the Intro for the full map of categories and consequences. Use the Cheatsheet when comparing patterns with similar shapes. The Field Notes cover the costs that become visible once an abstraction begins meeting real requirements. The Practice reference turns this into a refactoring exercise, because patterns make more sense when code has first had the courtesy to cause a problem.

Don't Panic: Design Patterns

Relevant careers