Design Patterns cheat sheet

1. 1How to use patternsWhat a design pattern is, the three families in the Gang of Four catalogue, and the two principles most patterns are built on.6 concepts

   1. 1Design patternA named, reusable solution to a design problem that keeps recurring in object-oriented code.
   2. 2Creational, structural, behaviouralCreational patterns control how objects are made (5).
   3. 3Program to an interfaceWrite code against what an object can do (an interface or abstract type), not which concrete class it is.
   4. 4Composition over inheritanceBuild behaviour by holding other objects and delegating to them, rather than by deep subclass chains.
   5. 5Reading pattern diagramsPattern books draw UML class diagrams: a box per class, a hollow triangle arrow for "implements or extends", a plain arrow for "uses", and a diamond for "holds…
   6. 6When not to use a patternA pattern adds classes and indirection.

   6 in this chapterOpen this chapter
2. 2Creational patternsThe five patterns that decide how objects get created, so calling code does not depend on concrete classes or messy constructors.5 concepts

   1. 1Factory MethodIntent: let a method decide which class to instantiate, so callers ask for "a transport" without naming the class.
   2. 2Abstract FactoryIntent: an interface for creating whole families of related objects, with one concrete factory per family.
   3. 3BuilderIntent: construct a complex object step by step, separating how it is assembled from what it ends up as.
   4. 4PrototypeIntent: create new objects by copying an existing, configured instance instead of building from scratch.
   5. 5SingletonIntent: ensure a class has exactly one instance and give global access to it.

   5 in this chapterOpen this chapter
3. 3Structural patternsThe seven patterns that compose classes and objects into larger structures while keeping them flexible.7 concepts

   1. 1AdapterIntent: convert the interface of an existing class into the one your code expects.
   2. 2BridgeIntent: split an abstraction from its implementation so the two can vary independently.
   3. 3CompositeIntent: compose objects into trees and treat single objects and groups the same way.
   4. 4DecoratorIntent: add behaviour to an object by wrapping it in another object with the same interface.
   5. 5FacadeIntent: one simple entry point in front of a complicated subsystem.
   6. 6FlyweightIntent: share the common, unchanging part of many similar objects instead of storing it in each one.
   7. 7ProxyIntent: a stand-in object with the same interface that controls access to the real one.

   7 in this chapterOpen this chapter
4. 4Behavioural patterns: requests and eventsPatterns for passing requests, events and state between objects without tying them tightly together.6 concepts

   1. 1Chain of ResponsibilityIntent: pass a request along a chain of handlers until one handles it or the chain ends.
   2. 2CommandIntent: turn a request into an object with everything needed to perform it, and often to undo it.
   3. 3IteratorIntent: walk through a collection one item at a time without exposing how it is stored.
   4. 4MediatorIntent: objects talk through one mediator instead of referring to each other directly.
   5. 5MementoIntent: capture an object's internal state as a snapshot so it can be restored later, without exposing its internals.
   6. 6ObserverIntent: when one object changes, all objects subscribed to it are notified automatically.

   6 in this chapterOpen this chapter
5. 5Behavioural patterns: varying behaviourPatterns for swapping algorithms, changing behaviour with state, fixing a skeleton of steps, and adding operations to object structures.5 concepts

   1. 1StrategyIntent: define a family of algorithms behind one interface and choose one at run time.
   2. 2StateIntent: an object changes its behaviour when its internal state changes, as if it changed class.
   3. 3Template MethodIntent: a base class fixes the steps of an algorithm and lets subclasses fill in some of them.
   4. 4VisitorIntent: add new operations to a fixed set of classes without changing them, by moving each operation into a visitor object.
   5. 5InterpreterIntent: represent the grammar of a small language as classes and evaluate sentences by walking the tree.

   5 in this chapterOpen this chapter
6. 6SOLID principlesThe five principles behind maintainable object-oriented code, each with the smell that tells you it is being broken.5 concepts

   1. 1Single Responsibility PrincipleA class or module should have one reason to change: it answers to one actor or concern.
   2. 2Open/Closed PrincipleCode should be open for extension but closed for modification: add behaviour by adding new code, not by editing working code.
   3. 3Liskov Substitution PrincipleAny subtype must be usable wherever its base type is expected, without surprising the caller.
   4. 4Interface Segregation PrincipleMany small, focused interfaces beat one large one; no class should be forced to implement methods it does not use.
   5. 5Dependency Inversion PrincipleHigh-level policy should depend on abstractions, and low-level details should implement them; neither depends directly on the other.

   5 in this chapterOpen this chapter
7. 7Principles beyond SOLIDShort rules that sit next to SOLID in code reviews, and the anti-patterns that appear when they are ignored.6 concepts

   1. 1Dependency injectionAn object receives its collaborators from outside, usually through its constructor, instead of creating them itself.
   2. 2DRYEvery piece of knowledge should have one authoritative place in the code.
   3. 3KISS and YAGNIPrefer the simplest design that works (KISS), and do not build for requirements you do not have yet (YAGNI).
   4. 4Law of DemeterA method should talk only to its own fields, its parameters and objects it creates, not reach through chains like order.customer.address.city.
   5. 5High cohesion, low couplingCohesion: things inside a module belong together.
   6. 6Common anti-patternsRecurring bad shapes: the god object that knows everything, spaghetti code with tangled control flow, copy-paste programming, and magic numbers.

   6 in this chapterOpen this chapter
8. 8Choosing a patternMap the problem in front of you to a pattern, and recognise the patterns already inside the frameworks you use.5 concepts

   1. 1Problem to pattern mapA quick lookup from symptom to candidate pattern.
   2. 2Patterns you already useExpress and Koa middleware is Chain of Responsibility, DOM events are Observer, Java I/O streams are Decorators, Spring beans default to singletons, and React…
   3. 3Patterns and first-class functionsIn languages with first-class functions, Strategy, Command and Template Method often shrink to passing a function, and Iterator becomes a generator.
   4. 4Telling similar patterns apartAdapter changes an interface; Facade simplifies a subsystem.
   5. 5Refactoring towards a patternStart with simple code and introduce a pattern when duplication or a growing conditional shows the need, in small tested steps.

   5 in this chapterOpen this chapter
9. 9Glossary, A to ZEvery concept in the sheet and the smaller terms it uses, in one list.51 terms

All 23 Gang of Four patterns with intent, when to use and a TypeScript sketch, plus SOLID, related principles and a problem to pattern map.