Design patterns are reusable, proven solutions to recurring design problems in software development, cataloged most famously by the Gang of Four (GoF) in their 1994 book. They provide a shared vocabulary for developers to communicate complex design ideas clearly and offer blueprints that improve maintainability, scalability, and testability of object-oriented code. Beyond the original 23 GoF patterns, modern software engineering has produced a rich set of architectural and distributed systems patterns — including CQRS, Event Sourcing, Circuit Breaker, Saga, and Hexagonal Architecture — that address the realities of microservices, cloud-native deployments, and distributed data. Mastering patterns means recognizing when one fits naturally, knowing when to compose multiple patterns together, and understanding that context is everything: the right pattern depends on consistency requirements, team size, language features, and system scale.
What This Cheat Sheet Covers
This topic spans 9 focused tables and 104 indexed concepts, 71 flashcards, 3 practice tests with 127 questions. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
Table 1: Creational Patterns — Object Construction
Creational patterns deal with one question: how an object comes into existence. Rather than scattering new calls throughout your code, these patterns put a controlled layer around instantiation — whether that means guaranteeing a single shared instance, assembling something complex step by step, or cloning an existing object instead of building from scratch.
| Pattern | Example | Description | |
|---|---|---|---|
class Logger { private static instance; static getInstance() { return instance ??= new Logger(); }} | • Ensures only one instance exists globally • provides a single access point for shared resources like loggers, caches, or configuration objects. | ||
abstract class Creator { abstract createProduct();}class ConcreteCreator extends Creator { createProduct() { return new ProductA(); }} | • Defines an interface for creating objects but lets subclasses decide which concrete class to instantiate • defers instantiation to subclasses. | ||
interface GUIFactory { createButton(); createCheckbox();}class WindowsFactory implements GUIFactory { ... } | • Provides an interface for creating families of related objects without specifying concrete classes • ensures all components in a family (e.g., UI components per platform) work together. | ||
class CarBuilder { setEngine(e) { ... return this; } setWheels(w) { ... return this; } build() { return new Car(...); }} | • Constructs complex objects step-by-step with a fluent interface • separates construction from representation, enabling multiple representations from the same process. | ||
class Shape { clone() { return Object.assign(new Shape(), this); }}const cloned = original.clone(); | • Creates new objects by cloning an existing instance rather than constructing from scratch • useful when instantiation is expensive or configuration varies only slightly between instances. | ||
class ConnectionPool { acquire() { return pool.pop() ?? new Connection(); } release(conn) { pool.push(conn); }} | • Manages a pool of reusable objects to avoid the cost of repeatedly creating and destroying expensive resources • clients borrow and return objects; common for DB connections and threads. |