Design Pattern

For a long time every company solved the same handful of problems from scratch. Keeping exactly one copy of a setting for the whole program. Leaving a calculation swappable so a second version can drop in later. Telling several other places that something just changed. Everyone ran into these, and none of them had a name.

That made code review unusually slow. Code review is the step where a colleague reads your change before it merges, and with no shared name you explain the idea from zero every time. Twenty minutes and a whiteboard sketch to justify "if we split it here, adding a third calculation later only touches this one file" — and the reviewer has no basis for telling a good structure from one person's taste.

A 1994 book changed that by naming twenty-three of these problems and their solutions. Once the same thing had the same name everywhere, a twenty-minute explanation became one word.

Under software architecture, design patterns sit in the design knowledge branch. That branch exists to hand you what earlier engineers already worked out, so the same thinking doesn't start over on every project.

A pattern is something you reach for after meeting a problem, not something you pick first. There are five steps.

1. Write the problem down in one sentence. Something like "the notification code lives inside the document save code, so every new notification means editing save." If that sentence won't come out, it's too early to look for a pattern.
2. Find out whether a problem of that shape already has a name. Wanting exactly one instance is Singleton. Wanting to swap between several approaches is Strategy. Wanting interested parties to pick up a change on their own is Observer.
3. Take the skeleton, not the code. A pattern is a layout — which pieces exist and who calls whom — rather than something to paste in. Book examples are usually written in one language, and the shape shifts depending on what you write in.
4. Say the name out loud on the team. A comment line or a file name is enough; the next person then knows where a new calculation goes without asking. Skip this and everything you did through step 3 stays a structure only you understand.
5. Drop it if it doesn't fit. If the code got harder to read after the pattern went in, back it out. Having a name is not proof of belonging in that spot.

Document saving at Pagedeck went through exactly these steps. Every save had to fire a notification, update the search index, and write an activity record, and all three lived inside the save code. Theo moved it to Observer: save announces only that a document was saved, and notifications, indexing, and records each pick that fact up. When a fourth consumer arrived the next quarter, the save code didn't change by a single line.

The moment to reach for one is the third time a problem of the same shape shows up. Solve it plainly the first time, note the resemblance the second, and generalize on the third. Two occurrences look alike often enough by accident; three is where the shape is real. Applying a pattern on the first occurrence freezes the structure before anyone knows which way it will grow.

There are three ways it goes wrong. First, picking the pattern and then bending the problem to fit it: a job that a single function would finish ends up with an interface and five classes, cohesion is no better than before, and the only growth is in files to read. Second, rebuilding something the language already gives you. In a language where functions are values, Strategy is a function passed as an argument; put a class hierarchy around it and the name is all that's left. Third, letting the name stand in for the reasoning. Once a pattern name is attached, review goes soft, and nobody checks whether coupling actually went up.

The good spots are just as clear: places where the number of variants will certainly grow, places several people edit at once, and work you already decided to spend on refactoring. Refactoring changes structure while behavior stays the same, and a pattern gives that work a destination.

"Let's make this an Observer. Notifications and the index both have to follow every save."

A proposal to pull the save path and the notification path apart, with the layout already agreed on through one name.

"It has a pattern name now, but it also has five new classes. Couldn't this be one function?"

The structure costs more than the problem is worth.

"Label it Strategy and the next person knows immediately where a new calculation goes."

The value of a pattern lands on the next reader more than on the code itself.

At Pagedeck the word comes up most often in code review. When someone comments "wouldn't a Factory be better here?" on one of Theo's changes, that single line draws the same picture for both of them of which piece moves where. Without the name, the same suggestion would take ten lines of comments.

Names can also end a conversation too early. When a review question gets answered with "it's a Singleton," people usually stop asking, even though the question worth asking is whether one instance for the whole program is right at all. This is where teams discover that the single instance can't be swapped for a fake in tests, which blocks unit testing across the board.

The most common belief is that more patterns make a better design. Knowing the names feels like evidence of skill, and interviews that ask for names by the dozen keep the belief alive. But a pattern is a trade: you pay in structural complexity to handle a complex problem. Pay when the problem is simple and what's left is debt. Changing one line means following five files, and a new hire meets a structure nobody can say what problem it solves. The people who could have explained it moved on two years ago.

The name causes its own confusion. People hear "design pattern" and think it's about how screens look. The word is used in the interface world too, but design here means engineering design, not visual design. A recurring screen layout is called a user interface (UI) pattern instead. Leave the two mixed up and engineers and designers spend half a meeting using one word for two different things.