What problem do structural design patterns solve, and how do they differ from creational and behavioral patterns?
answer
- create / compose / converse = creational / structural / behavioral
- seven: Adapter Bridge Composite Decorator Facade Flyweight Proxy
- same class diagram, different intent
- favour composition over inheritance
- every layer costs a stack frame
basics
~20 sStructural 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.
solid answer
~50 sThe Gang of Four catalog splits patterns into three families by what they organize. Creational patterns (Factory Method, Builder, Singleton) control instantiation. Behavioral patterns (Strategy, Observer, Command) control how responsibilities and messages flow between collaborators at runtime. Structural patterns control shape: how you assemble existing classes and objects into bigger structures without rewriting them. The seven are Adapter (convert one interface into another), Decorator (attach responsibilities dynamically), Proxy (control access to an object), Facade (a simple entry point to a complex subsystem), Composite (treat part-whole trees uniformly), Bridge (let an abstraction and its implementation vary independently), and Flyweight (share fine-grained objects to save memory). Most are built from the same two primitives, composition plus interface conformance, so their class diagrams look alike. What distinguishes them is intent, not structure, which is why you name them after the problem they solve.
go deeper
Name the three families, state that structural patterns are about composing objects into larger structures, and list two or three of the seven with a one-line intent each.
Give all seven intents crisply and explain that the class diagrams overlap so intent is the discriminator; mention composition over inheritance.
Contrast the near-identical wrappers by whose interface is exposed and why the indirection exists; give real examples (HTTP client stack, UI widget tree) and name the costs.
Frame patterns as shared vocabulary for reviews and architecture rather than code to copy; discuss when language features subsume them, when a layer is unjustified, and how these intents scale up to service boundaries.
## Vocabulary first - **Design pattern** — a named, reusable solution to a recurring design problem, described in terms of participating roles rather than concrete code. It is a description, not a library. - **Gang of Four (GoF)** — shorthand for the 1994 book *Design Patterns* by Gamma, Helm, Johnson, Vlissides, which catalogued 23 patterns and coined the three-family split used here. - **Interface** — the set of operations a caller may invoke. Language-agnostic: it can be a Java/C# `interface`, a C++ abstract base class, a Go interface, a TypeScript type, a Python protocol, or just a documented set of methods in a dynamically typed language. - **Composition** — object A holds a reference to object B and calls it, rather than inheriting from it. - **Delegation** — A receives a call and forwards it to B, possibly changing something on the way in or out. ## The three families | Family | Organizing question | Examples | |---|---|---| | Creational | *How does this object come into existence?* | Factory Method, Abstract Factory, Builder, Prototype, Singleton | | Structural | *How are objects/classes plugged together into a bigger whole?* | Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy | | Behavioral | *Who is responsible for what, and how do they communicate?* | Strategy, Observer, Command, State, Template Method, Visitor, Iterator, Chain of Responsibility, Mediator, Memento, Interpreter | The families overlap in practice — a Facade is often created by a factory, a Decorator chain is often assembled by a builder — but the split is a useful index: when you are stuck, ask which of the three questions you are actually trying to answer. ## The seven structural patterns and their one-line intents 1. **Adapter** — make an existing class usable through an interface the client already expects. *Interface conversion after the fact.* 2. **Decorator** — add behaviour to an individual object at runtime without changing its class or affecting other instances of that class. *Attached responsibilities.* 3. **Proxy** — provide a stand-in for another object to control access to it (lazy creation, remoteness, permissions, caching, logging). *Controlled access.* 4. **Facade** — offer one high-level interface over a set of interfaces in a subsystem so ordinary use is easy. *Simplified subsystem entry point.* 5. **Composite** — arrange objects into a tree of parts and wholes, and let clients treat individual objects and compositions identically. *Uniform part-whole composition.* 6. **Bridge** — split one concept into two hierarchies, an abstraction and an implementation, joined by composition, so both can be extended independently. *Decoupling abstraction from implementation.* 7. **Flyweight** — share one immutable object across many logical occurrences, passing the varying part in from the outside. *Sharing fine-grained state.* ## Why the structures look identical Five of the seven (Adapter, Decorator, Proxy, Bridge, Facade) reduce to "an object holds another object and forwards calls to it". If you screenshot only the class diagram of an Adapter and a Proxy you often cannot tell them apart. The distinguishing information lives in three places: - **Whose interface wins.** Decorator and Proxy expose the *same* interface as the wrapped object; Adapter exposes a *different* one (the client's); Facade exposes a *new, smaller* one; Bridge deliberately keeps the two interfaces different because they evolve for different reasons. - **Why you added the indirection.** Adapter: incompatibility you did not choose. Decorator: optional, stackable extra behaviour. Proxy: access control/lifecycle/location. Facade: cognitive load. Bridge: combinatorial class explosion. - **Who decides, and when.** Decorators are typically composed by the client at runtime and can be stacked; Proxies are usually fixed and singular; Bridges are wired at construction. That is why interviewers ask "what is the *intent*" rather than "draw the diagram" — the diagram is the cheap half. ## Class-level vs object-level GoF further tagged patterns as class-scoped (using inheritance, fixed at compile time) or object-scoped (using composition, changeable at runtime). Only Adapter has a class form (inherit from both the target interface and the adaptee, where the language allows it); every other structural pattern is object-scoped. This is the concrete expression of the GoF principle *"favour object composition over class inheritance"* — composition keeps the coupling to a published interface, avoids fragile base classes, and can be rearranged while the program runs. ## Edge cases and honest caveats - **The names are for communication, not virtue.** Wrapping something does not become better because you called it a Decorator. The value is that a reviewer reads the name and instantly knows the constraints ("same interface, stackable, no shared state"). - **Real code is usually a blend.** A caching HTTP client is a Proxy in intent, implemented as a Decorator in mechanics, sitting behind a Facade. Saying "it is a cache proxy" is more useful than arguing the taxonomy. - **Indirection is not free.** Each layer costs a stack frame, an allocation, a step in the debugger, and one more file a newcomer must open. Structural patterns buy flexibility with comprehensibility; only pay when the flexibility is actually needed. - **Some patterns are language features elsewhere.** Mixins, traits, extension methods, prototypal delegation, and dynamic proxies can express Decorator or Adapter with no explicit pattern classes. The concept survives; the boilerplate does not.
- Name a structural pattern that changes the interface and one that preserves it.Adapter changes it: the client talks to a target interface the adaptee never implemented. Decorator and Proxy preserve it, which is exactly what lets a decorator be stacked or a proxy be dropped in transparently. Facade neither preserves nor converts — it invents a new, smaller interface over many objects.
- Is Composite a structural or behavioral pattern, given that it is about traversing trees?Structural. It is about how objects are assembled into a part-whole hierarchy and presented through one interface. Traversal of that structure is a separate concern usually handled by behavioral patterns such as Iterator or Visitor.
- Why did GoF emphasise composition over inheritance in this family?Inheritance is fixed at compile time, exposes the parent's internals, and multiplies classes for each combination of features. Composition binds only to a published interface, can be rewired at runtime, and lets features combine linearly instead of multiplicatively.
Think of a stereo system. Creational = the factory that manufactures the speakers. Structural = the cables, plug adapters, splitters and the single remote that let mismatched boxes act as one system. Behavioral = the protocol the boxes use to tell each other to play, pause and change volume.
saying these in an interview costs you the question
- Claiming structural patterns are 'about class diagrams' rather than about intent.
- Saying Adapter, Proxy and Decorator are 'the same pattern' because the code looks similar — the constraints and reasons differ.
- Treating the three families as strict, mutually exclusive boxes instead of an index.
- Assuming a pattern must be implemented with explicit pattern classes; many languages express the same intent with built-in features.
- Adding wrappers 'for flexibility' with no concrete second variant in sight.