Structural Patterns

Bridge splits a design into two separate hierarchies — an abstraction (what the thing is) and an implementation (how it does its work) — connected by a reference instead of inheritance, so each side can grow independently.

Composite arranges objects into part-whole trees. A single item and a group of items implement the same interface, so client code calls the same method on either one and never has to check which it is.

Decorator wraps an object inside another object that implements the same interface. The wrapper adds behavior before or after passing the call to the wrapped object. You add features by composing wrappers at runtime instead of writing subclasses.

Facade puts one simple, higher-level object in front of a complicated group of classes. Clients call the facade instead of wiring the parts together themselves, so calling code is shorter and depends on fewer internal types.

Flyweight saves memory when a program needs a huge number of similar objects. Instead of one object per occurrence, identical parts are stored once and shared; the parts that differ per occurrence are passed in by the caller.

Proxy is a stand-in object that implements the same interface as a real object and forwards calls to it. Because callers go through the proxy, it can control access — delay creation, check permissions, cache, or talk over a network — without the caller knowing.

Structural patterns describe how to compose classes and objects into larger structures, usually by wrapping or nesting them. Creational patterns are about how objects get created; behavioral patterns are about how objects talk to each other and split responsibility.

A class adapter inherits from the adaptee and the target, translating inside itself. An object adapter holds an adaptee instance as a field and delegates. Composition is more flexible and works in single-inheritance languages, so it's the default.

Bridge is planned before you write either side, to let two dimensions vary independently. Adapter is added afterwards to make an existing, incompatible interface usable. Same shape on a diagram, opposite intent and timing.

A Component interface declares the operation. A Leaf implements it directly (base case). A Composite holds a list of Components and implements the operation by calling it on each child and combining the results (recursive case). The client only ever sees Component.

Decorator adds extra behavior to an object; Proxy controls access to it (lazy creation, remote calls, permission checks, lifecycle). Both keep the interface. Adapter is different again: it changes one interface into another so incompatible code can work together.

Each wrapper runs its logic around the call to the next one, so the outermost wrapper sees the call first and the result last. Swapping two wrappers changes what each one observes and what it can prevent, which changes behavior.

Facade simplifies many classes behind one easy entry point. Adapter converts one interface into a different one a client already expects. Mediator makes peers talk through a hub instead of each other. Proxy keeps the same interface but controls access to one object.

Ask: "would this value be the same for every place the object is used?" If yes it is intrinsic and can be shared; if it changes per use (position, owner, timestamp) it is extrinsic and must be passed in. Putting per-use data in the shared object corrupts all users.

Their structures look alike, but the intent differs. Proxy controls access to the object — whether, when, and from where you reach it — and usually creates or owns it. Decorator adds extra behavior to a request that always reaches the wrapped object, and is composed from outside.

Adapter changes an object's interface so an existing client can use it. Decorator keeps the same interface and adds behaviour, and decorators can be stacked. Proxy also keeps the same interface but controls access — lazily creating, checking permissions, caching or reaching a remote object.

Putting add/remove on the shared interface makes leaves and containers fully interchangeable (transparency) but forces leaves to implement operations that are meaningless for them. Putting them only on the container is type-safe but makes clients check the type again.

Either leave the subsystem reachable so that caller uses it directly (flexible, weaker boundary), or add the capability to the facade (keeps the boundary, but the facade grows). A middle option is a deliberate escape hatch that exposes the underlying object.

Compare the wrapper's interface to the wrapped thing's. Different interface, same behavior = Adapter. Same interface, extra behavior = Decorator. Same interface, controlled access = Proxy. New simpler interface over many objects = Facade.

Spot the two independent axes (notification kind × delivery channel). Keep the domain-facing one — the notification kind — as the abstraction hierarchy, extract the mechanism — the channel — into an interface, and have each notification hold and delegate to a channel.

add() must reject cycles (a node must not contain itself or an ancestor), keep parent references consistent by detaching the child from its old parent, and enforce any rules about which children are allowed. Sharing one node under two parents breaks parent pointers and double-counts totals.

All reuse objects, but for different reasons. Flyweight shares immutable value-like objects concurrently to save memory. A pool lends out mutable objects one user at a time and takes them back. A cache stores results to avoid recomputation and may evict them. Singleton just limits a class to one instance.

Make the lazy creation thread-safe (two threads can both see "not created yet"), decide what happens if creation fails on first call, and remember the proxy is a different object from the real one — identity checks, equality, and type casts on the concrete class can break.

Composite arranges objects into a tree where a container and a single item share one interface, so client code can call the same operation on a leaf or on a whole subtree without checking which it has. The trade-off is whether add/remove sit on the shared interface (uniform but unsafe for leaves) or only on containers (type-safe but forces clients to distinguish).

Options: emulate the missing behavior inside the adapter, expose a capability check so callers can ask first, narrow the target interface so nobody has to lie, or reject the adaptee. Throwing "unsupported" silently is the worst choice.

Adapter is applied after the fact to make two existing, mismatched interfaces work together. Bridge is designed up front so an abstraction and its implementation can vary independently. Same shape, opposite timing and intent.

Strategy swaps one interchangeable algorithm for a single operation and is often changed per call. Bridge splits an entire abstraction from an entire implementation platform, usually fixed for the object's life, to stop a two-dimensional class explosion.

Composite holds many children to represent a whole made of parts; Decorator wraps exactly one object to add behaviour to it. Visitor is not a structure at all — it adds new operations over an existing Composite tree without editing the node classes.

The wrapper is a different object than the one wrapped, so reference comparison, type checks, and casts to the concrete class fail. Also, when the inner object calls its own methods, those calls skip the wrappers entirely.