dp-structural-patterns

# Structural Design Patterns (GoF Structural Patterns) Structural patterns explain how to compose classes and objects into larger structures while keeping those structures flexible and efficient. Object composition offers far more runtime flexibility than static class inheritance. --- ## 🔌 1. Adapter ### 1.1 Intent and Motivation Converts a class's interface into another interface that clients expect. It lets classes with incompatible interfaces work together. ```mermaid classDiagram class Client class Target { <<interface>> +request() } class Adapter { -adaptee: Adaptee +request() } class Adaptee { +specificRequest() } Client --> Target Target <|.. Adapter Adapter o-- Adaptee : translates call ``` --- ## 🌉 2. Bridge ### 2.1 Intent and Motivation Decouples an abstraction from its implementation, allowing both to vary independently through separate hierarchies linked by composition. ```mermaid classDiagram class Abstraction { -impl: Implementation +feature() } class RefinedAbstraction { +feature() +advancedFeature() } class Implementation { <<interface>> +method1() +method2() } class ConcreteImplA { +method1() +method2() } class ConcreteImplB { +method1() +method2() } Abstraction <|-- RefinedAbstraction Abstraction o-- Implementation : bridge Implementation <|.. ConcreteImplA Implementation <|.. ConcreteImplB ``` --- ## 🌳 3. Composite ### 3.1 Intent and Motivation Composes objects into tree structures to represent part-whole hierarchies. It lets clients treat individual objects and compositions of objects uniformly. ```mermaid classDiagram class Component { <<interface>> +execute() } class Leaf { +execute() } class Composite { -children: List~Component~ +add(c: Component) +remove(c: Component) +execute() } Component <|.. Leaf Component <|.. Composite Composite o-- Component : contains ``` --- ## 🎀 4. Decorator (Wrapper) ### 4.1 Intent and Motivation Attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. ```mermaid classDiagram class Component { <<interface>> +operation() } class ConcreteComponent { +operation() } class BaseDecorator { -wrappee: Component +operation() } class ConcreteDecoratorA { +operation() +addedBehavior() } Component <|.. ConcreteComponent Component <|.. BaseDecorator BaseDecorator o-- Component BaseDecorator <|-- ConcreteDecoratorA ``` --- ## 🏛️ 5. Facade ### 5.1 Intent and Motivation Provides a simplified, high-level interface to a complex subsystem made up of multiple classes, making the subsystem easier to use and decoupling clients from internal details. ```mermaid classDiagram class Client class VideoConverterFacade { +convertVideo(file, format) } class AudioMixer class BitrateReader class CodecFactory Client --> VideoConverterFacade VideoConverterFacade ..> AudioMixer VideoConverterFacade ..> BitrateReader VideoConverterFacade ..> CodecFactory ``` --- ## 🪶 6. Flyweight ### 6.1 Intent and Motivation Fits a huge number of objects into RAM by sharing common state (intrinsic state) across multiple objects instead of keeping all the data in every instance (extrinsic state). ```mermaid classDiagram class FlyweightFactory { -flyweights: Map +getFlyweight(key) Flyweight } class TreeType { -name -color -texture +draw(canvas, x, y) } class Tree { -x -y -type: TreeType +draw(canvas) } FlyweightFactory o-- TreeType Tree o-- TreeType : shares intrinsic state ``` --- ## 🛡️ 7. Proxy ### 7.1 Intent and Motivation Provides a substitute or placeholder for another object to control access to it. Common types: Remote Proxy, Virtual Proxy (Lazy Loading), Protection Proxy (Access Control), and Cache/Log Proxy. ```mermaid classDiagram class ServiceInterface { <<interface>> +operation() } class RealService { +operation() } class Proxy { -realService: RealService +operation() } ServiceInterface <|.. RealService ServiceInterface <|.. Proxy Proxy o-- RealService : controls access ``` --- ## 🅨 8. C++ Structural Idioms (Pikus) Classic GoF structural patterns have C++-specific realizations and pitfalls. - **Decorator limitations**: a decorated object is not owned by the decorator, and cross-casting breaks the abstraction — a `VeteranUnit` wrapping a `Knight` *is a* `Unit` but not a `Knight`, so `vk.charge()` fails. A compile-time **policy** decorator sidesteps this with a variadic template-template pack: ```cpp template <typename T, template <typename, typename> class... Policies> class Value : public Policies<T, Value<T, Policies...>>... {}; ``` This is why C++ favors **adapters and policies over runtime decorators**. - **Type erasure** (a structural façade over unrelated types): intrusive inheritance (what `shared_ptr`/`std::function` do, hiding the deleter behind a base) versus a **non-allocating** form storing a function pointer plus an aligned buffer (`alignas(8) char buf_[8]`) and reifying via an `invoke_destroy<Deleter>` template. `std::any`/`any_cast` is the standard type-erased value. - **RAII as the structural backbone**: `mutex_guard` and "very modern RAII" implemented with coroutines (`co_resource`) place acquisition and release textually adjacent, at the cost of suspend/resume. - **CRTP** (`class D : public B<D>`) provides static-polymorphic "wrappers" where a virtual proxy would be too costly; make a non-virtual base destructor `protected` to prevent polymorphic deletion. - **Local buffer optimization** (`small_vector`, `small_queue`): a union of an inline buffer and a heap pointer delivers flyweight-like allocation avoidance, at the cost of iterator-invalidation guarantees, possible throwing moves, and heavy `reinterpret_cast` boilerplate. ## ⚖️ Comparative Matrix of Structural Patterns | Pattern | Problem Solved | Structural Strategy | | :--- | :--- | :--- | | **Adapter** | Incompatible interfaces between legacy/third-party systems | Wraps an existing object, translating calls | | **Bridge** | Combinatorial subclass explosion in 2 orthogonal dimensions | Separates Abstraction and Implementation via a reference | | **Composite** | Recursive handling of hierarchical (tree) structures | Treats leaves and composite nodes with the same interface | | **Decorator** | Dynamic addition of responsibilities without inheritance | Wraps the real object, delegating and adding behavior | | **Facade** | Complexity of subsystem initialization/orchestration | Simplified entry point for multiple components | | **Flyweight** | High memory use with millions of similar objects | Separates intrinsic (shared) from extrinsic state | | **Proxy** | Direct access to a heavy, remote, or protected object | Intercepts requests, applying lazy load, auth, or cache |