Design Patterns

Whole families that must match — and the cost of adding one more kind of thing.

Making an incompatible interface fit — and the one file that should know the vendor's vocabulary.

Two things that vary independently, kept from multiplying.

Assembling a complicated object step by step — and the validation you can only do at the end.

Pass the request along until somebody claims it — and the case nobody handles.

A request as an object — and the undo stack you get almost for free.

Treating one thing and many things identically — and the method that does not belong on a leaf.

Adding behaviour by wrapping rather than subclassing — and why the order of the wrappers is a real decision.

One door into a subsystem — and why the door must not become the only way in.

Letting a subclass decide what to construct — and why a plain function is usually enough.

Sharing the heavy part between many objects — and the split that makes it possible.

A grammar as a class hierarchy — and why you should almost always use a parser generator instead.

Walking a collection without knowing its shape — and why laziness is the part that matters.

A hub instead of a mesh — and the risk that the hub becomes the program.

A snapshot that only its owner can read — and why undo usually wants commands instead.

One-to-many notification without the sender knowing who is listening — and the leak it invites.

Copying an existing object instead of constructing one — and the depth of the copy.

A stand-in with the same interface — and the fact that callers cannot tell is both the feature and the hazard.

One instance, globally reachable — and why the second half of that is the problem.

Behaviour that follows the mode — and how the illegal transitions stop being reachable.

The algorithm as a parameter — and why in most languages it is now just a function.

The skeleton fixed, the steps varied — inheritance's one genuinely good use, and its limits.

Adding an operation without editing the classes — and the price it charges for that.