Design Patterns

one class is four thousand lines and every feature branch touches it.

God objectArchitecture

there is a 3 in the middle of the expression and nobody left a note saying which three that is.

Magic numberPatterns

two tests passed on their own and failed together, because the thing they both reached for kept state between them.

SingletonPatterns

there is an interface with one implementation and a config flag that has never been anything but its default.

Premature abstractionPatterns

adding one field meant small edits in eleven files, and the review caught the two you missed.

Shotgun surgeryPatterns

understanding one method meant opening five files up and down the hierarchy, and then going back up again.

Yo-yo problemPatterns

someone described a solution in four words and everyone in the room pictured roughly the same code.

Design patternPatterns

somebody says a pattern is 'GoF' and means it came from the 1994 book rather than from a framework.

Gang of FourPatterns

another team reached into the field directly, and now you cannot rename it without breaking them.

EncapsulationArchitecture

the same call site does three different things depending on what was passed in, and there is no branch anywhere.

PolymorphismPatterns

you got twenty methods you never asked for along with the one you wanted, and you cannot give any of them back.

InheritancePatterns

you said it out loud — a Stack is a List — and it sounded fine right up until someone called insert in the middle of it.

Is-a vs has-aPatterns

the subclass needed one method overridden and inherited four others it never wanted and cannot remove.

Composition over inheritanceArchitecture

the method body is one line that calls the same method on a field, and that is the whole class's job for that method.

DelegationPatterns

someone rejected the pull request citing a five-letter acronym, and only two of the five letters were actually about the problem.

SOLIDPatterns

two teams keep editing the same class for two entirely unrelated reasons and keep colliding.

Single responsibilityArchitecture

adding the fourth payment method meant editing the same switch statement for the fourth time.

Open–closed principlePatterns

the subclass threw on a method the parent promised, and every caller written against the parent was suddenly wrong.

Liskov substitution principlePatterns

you implemented an eleven-method interface to get at one of them and threw not-implemented from the other ten.

Interface segregation principlePatterns

the business rules import the Postgres driver, so testing a discount calculation needs a database.

Dependency inversionArchitecture

you wrote order.getCustomer().getAddress().getPostcode() and a change three objects away broke your line.

Law of DemeterArchitecture

the class asks for what it needs in its constructor and never goes looking, so a test can hand it anything.

Dependency injectionPatterns

you stopped writing the loop and started writing the thing the framework calls, and you no longer decide when.

Inversion of controlPatterns

the class asks a global object for what it needs mid-method, so its dependencies are invisible until it runs.

Service locatorPatterns

the base class does the work and calls a method for the object it needs, and each subclass answers that with a different class.

Factory methodPatterns

you swap one object at startup and the whole family of things it creates changes together, consistently.

Abstract factoryPatterns

you set five things by name across five lines and call build, and the object does not exist until the last one.

Builder patternPatterns

the object holds another object and forwards most calls to it, and which pattern that is depends entirely on why.

WrapperPatterns

the library's method was called differently and returned the wrong shape, so you wrote a class that speaks both.

Adapter patternPatterns

you replaced eleven calls across four classes with one method, and callers stopped needing to know the order.

Facade patternPatterns

you wrapped the same interface in retries, then logging, then caching, and the caller still sees one thing.

Decorator patternPatterns

the object looks and behaves exactly like the real one, and its whole job is deciding whether the call gets through.

Proxy patternPatterns

the class takes the algorithm as a constructor argument, and choosing a different one is a different argument.

Strategy patternPatterns

the object's behaviour changed after a call and nothing branched — it had swapped the object it was delegating to.

State patternPatterns

the base class runs the five steps in order and leaves two of them abstract for you to write.

Template methodPatterns

you changed one field and four other things updated, and finding out which four meant reading a subscription list.

Observer patternPatterns

the request became an object with an execute method, so you could put it in a queue, log it and undo it.

Command patternPatterns

you walked the collection without knowing whether it was an array, a tree or a paged remote call.

Iterator patternPatterns

you added a new operation over the whole tree by writing one class, and did not touch any of the node types.

Visitor patternPatterns

instead of returning null you returned something that implements the interface and does nothing, and the null checks disappeared.

Null objectPatterns

the invalid cases return in the first four lines, and the rest of the method is not indented at all.

Guard clausePatterns

two of them with the same contents are interchangeable, so you never update one — you replace it.

Value objectPatterns

two of them with identical fields are still different things, because the thing that makes them the same is the id.

EntityPatterns

you can change these five objects together in one transaction, and anything outside them has to wait its turn.

AggregatePatterns

the objects have only fields and accessors, and every rule about them lives in a class ending in Service.

Anaemic domain modelPatterns

the code asks for the customer as if from an in-memory collection, and where it actually came from is somewhere else.

Repository patternPatterns

the object has a save method on it, so the thing that models an order also knows the table it lives in.

Active recordPatterns

the domain object has no idea a database exists, and a separate class knows which column each field came from.

Data mapperPatterns

the browser posted to a controller, which changed the model and picked a view, and the view read the model itself.

Model-view-controllerPatterns

the same use case runs from an HTTP handler, a message consumer and a test, and none of them is the primary one.

Hexagonal architecturePatterns

entities, then use cases, then adapters, then frameworks — and nothing in an inner circle names anything outside it.

Clean architecturePatterns

you called it twice with the same arguments, got the same answer, and nothing anywhere else changed.

Pure functionPatterns

nothing that was handed out can be changed, so you stopped copying defensively and stopped worrying about who else holds it.

ImmutabilityPatterns

the function's argument is another function, and what it actually does depends entirely on what you passed.

Higher-order functionPatterns

the test passed alone and failed in the suite, and the difference was something another test had left behind.

Global mutable statePatterns

two modules import each other, and which one is initialised first decides whether it works.

Circular dependencyPatterns

money is a decimal, the email is a string, and the validation for both is repeated in nine call sites.

Primitive obsessionPatterns

the method calls five getters on another object and one on itself, so it belongs on that other object.

Feature envyPatterns