Design Pattern
- K2C-2-1Singleton PatternMay 22, 2026
One instance per process, global access point — widely considered an anti-pattern; covers Meyers singleton, thread safety, testability problems, and modern alternatives (DI, `std::call_once`, `inline` variable).
- K2C-2-2Factory Method PatternMay 22, 2026
Defer instantiation to subclasses or callbacks — base defines the algorithm, derived (or a function) decides which concrete product to create; covers classic virtual form, modern `std::function`/template alternatives, and the distinction from a "static factory function".
- K2C-2-3Abstract Factory PatternMay 22, 2026
Create families of related objects without naming concrete classes — one factory object per family variant; covers classic GoF form, modern template/policy alternatives, and the trade-off vs Factory Method.
- K2C-2-4Builder PatternMay 22, 2026
Construct a complex object step by step, separating *what to build* from *how to assemble* — covers fluent interface with `std::move`, classic GoF director form, named-parameter idiom, and comparison with Abstract Factory.
- K2C-2-5Prototype PatternMay 22, 2026
Create new objects by cloning an existing instance — virtual `clone()` for polymorphic copy; covers deep vs shallow copy, prototype registries, copy-and-swap, and how `std::variant` + value semantics can replace it.
- K2C-2-6Adapter PatternMay 22, 2026
Wrap an incompatible interface so client code can talk to it through the interface it already expects — object-adapter via composition or class-adapter via multiple inheritance.
- K2C-2-7Bridge PatternMay 22, 2026
Decouple an abstraction hierarchy from its implementation hierarchy so the two can vary independently — composition instead of a combinatorial inheritance tree.
- K2C-2-8Composite PatternMay 22, 2026
Treat individual objects and compositions of objects uniformly through a shared interface — recursive tree structure where leaves and containers respond to the same operations.
- K2C-2-9Decorator PatternMay 22, 2026
Attach responsibilities to an object dynamically by wrapping it in an object with the same interface — composition-based alternative to subclassing for behavior extension.
- K2C-2-10Facade PatternMay 22, 2026
Provide a single, simplified interface to a complicated subsystem of classes — clients depend on the facade, not the subsystem's internals.
- K2C-2-11Flyweight PatternMay 22, 2026
Share fine-grained immutable state across many objects to cut memory use — split intrinsic (shared) from extrinsic (per-instance) state and intern the intrinsic part.
- K2C-2-12Proxy PatternMay 22, 2026
Surrogate object exposing the same interface as a real subject to control access — used for lazy initialization, remote calls, permission checks, smart references, and caching.
- K2C-2-13Chain of Responsibility PatternMay 22, 2026
Pass a request along a chain of handlers — each decides to handle or forward, decoupling sender from receiver and avoiding monolithic if/else dispatch.
- K2C-2-14Command PatternMay 22, 2026
Encapsulate a request as an object — enables parameterizing callers, queueing/logging requests, and supporting undo/redo.
- K2C-2-15Iterator PatternMay 22, 2026
Sequential access to elements of an aggregate without exposing its internal representation — in C++ the canonical iterator pattern is baked into the language via `begin`/`end`, range-based `for`, and C++20 ranges.
- K2C-2-16Mediator PatternMay 22, 2026
Centralize complex many-to-many interactions among components into a single mediator object, so components only talk to the mediator, not to each other.
- K2C-2-17Memento PatternMay 22, 2026
Capture an object's internal state into an opaque token so it can be restored later, without exposing internals to outside code.
- K2C-2-18Observer PatternMay 22, 2026
Define a one-to-many dependency so when a subject changes state, all dependents (observers) are notified automatically — the foundation of event-driven and reactive programming.
- K2C-2-19State PatternMay 22, 2026
Object alters behavior when its internal state changes — looks like it changed class; encapsulates state-dependent code as separate objects with transitions wired between them.
- K2C-2-20Strategy PatternMay 22, 2026
Define a family of interchangeable algorithms, encapsulate each, and let the client pick or swap one at runtime via composition — algorithm varies independently of the code that uses it.
- K2C-2-21Template Method PatternMay 22, 2026
Define the skeleton of an algorithm in a base class, defer specific steps to subclasses — invert control so the base orchestrates and the subclass fills in the variable steps.
- K2C-2-22Visitor PatternMay 22, 2026
Separate an algorithm from the object structure it operates on by double dispatch — each element accepts a visitor and calls back the visit method matching its concrete type; lets you add operations without modifying the elements.
- K2C-2-23Interpreter PatternMay 22, 2026
Define a grammar as a class hierarchy where each rule maps to a node, then walk the resulting AST to evaluate sentences in the language — useful for tiny DSLs; for anything non-trivial, use a parser generator instead.
- K2C-2-24CRTP (Curiously Recurring Template Pattern)May 22, 2026
A class derives from a template instantiated with itself (`class D : public Base<D>`), giving the base static access to the derived type — enables zero-overhead static polymorphism, mixins, and the Barton–Nackman trick.
- K2C-2-25Policy-Based DesignMay 22, 2026
Compose class behavior by passing orthogonal **policies** as template parameters that the host class inherits from — compile-time Strategy with zero runtime cost; popularized by Alexandrescu's *Modern C++ Design*.