codejump
Academy

Design Patterns

23 pages · about 138 min of reading

  1. 01Singleton patternThe guarantee that exactly one instance can exist, where it earns its place (database pools, caches, config), the global state it costs, and why it breaks on serverless.
  2. 02Factory Method patternHiding which concrete class gets built behind one function, the indirection it costs when the choice might never grow, and the leak when a return type still names the class.
  3. 03Abstract Factory patternGuaranteeing a whole family of related objects ships together, the extra interface every product carries, and the mismatch when a factory returns the wrong family.
  4. 04Builder patternReplacing a constructor drowning in optional parameters, the extra code it costs for objects simple enough not to need it, and build() handing back the same object twice.
  5. 05Prototype patternCloning a configured instance instead of rebuilding from scratch, the per-field copy it costs, nested fields included, and a shallow clone() copying a reference, not a value.
  6. 06Adapter patternTranslating an interface you cannot change into the one callers expect, the extra hop every call pays, and the moment it adds behavior and becomes a Decorator.
  7. 07Decorator patternStacking behavior onto one object at a time without subclassing, the layers it costs to read through when debugging, and the fixed wrap order every decorator must respect.
  8. 08Facade patternHiding a multi-step subsystem behind one simple call, the second thing to maintain the facade can become, and the wall it becomes once it is the only way in.
  9. 09Proxy patternControlling access to, or deferring the cost of, an object behind its own interface, the extra hop easy to forget, and the moment it carries logic and becomes a Decorator.
  10. 10Bridge patternLetting two dimensions of variation grow independently instead of multiplying into N times M classes, the two hierarchies it costs, and the if/else sneaking that growth back.
  11. 11Composite patternTreating a single object and a group of them through one interface, the cost every leaf pays for methods it may never use, and a leaf that accepts children it cannot hold.
  12. 12Flyweight patternSharing the identical, expensive part of many objects instead of duplicating it, the strict immutability it demands, and one write to shared state corrupting every instance.
  13. 13Strategy patternSwapping an algorithm without touching the class that uses it, the interface every strategy must implement even for a one-off, and reaching for it before a second case exists.
  14. 14State patternLetting an object swap what it can do next, decided from inside itself, the state class and transition table it costs, and two states that disagree who owns a transition.
  15. 15Template Method patternFixing the step order of an algorithm in a base class while subclasses fill in the rest, the subclassing it costs to change one step, and a base class open to rewrites.
  16. 16Observer patternNotifying many listeners without the subject knowing who they are, the leak a forgotten unsubscribe causes silently, and why every event system pairs subscribe with teardown.
  17. 17Mediator patternRouting communication between many objects through one hub, the god object the hub itself can become, and the temptation to route every interaction through it "to be safe."
  18. 18Chain of Responsibility patternTrying handlers one at a time until one accepts the request, the dead end when a request reaches the last link unhandled, and why every chain needs a terminal case.
  19. 19Command patternTurning "do this" into an object that can be queued, logged or undone, the class every action now needs, and a command that reaches into global state instead of its own.
  20. 20Memento patternTurning "go back to this" into an object kept separate from undo logic, the snapshot cost that grows with saved state, and a setter turning a saved state into a mutable copy.
  21. 21Iterator patternWalking a collection without exposing how it is stored, the extra object between caller and data it costs, and the wrong answer when next() runs past the end or data mutates.
  22. 22Visitor patternAdding a new operation to a fixed set of classes without editing them, the every-visitor update a new node type costs, and why it fails once classes change more than the ops.
  23. 23Interpreter patternEvaluating a small tree of grammar rules one node at a time, the class per rule that costs fast past a toy language, and the point a real parser beats one more class.