Summary (2)
Quick reference for structural patterns. A summary table alone cannot separate Adapter, Decorator, and Proxy — they often share the same wrapper shape. Use the three-question discriminator below before memorizing pros/cons.
Three-question discriminator (Adapter vs Decorator vs Proxy)
| Question | Adapter | Decorator | Proxy |
|---|---|---|---|
| Does the interface change? | Yes — adaptee has a different API; adapter implements the target | No — same interface as the wrapped object | No — same interface as the real subject |
| Does every call always forward? | Usually translates then forwards (one-to-one mapping) | Yes — adds behavior and always delegates | No — may short-circuit (cache, deny, lazy-load stub) |
| Primary intent | Reuse an existing class with the wrong interface | Add responsibilities dynamically without subclassing | Control access / stand in for the real object |
Interview one-liner: same diagram, different force — name the force, not the arrows.
For depth, prefer the individual structural pages (Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy) over this summary alone.
| Pattern Name | Distinctive Feature | Applicability | An Example | Pros | Cons |
|---|---|---|---|---|---|
| Adapter | Bridges incompatibilities between interfaces | When you want to use an existing class whose interface is not compatible with the rest of the code | Power adapter for different plug types | Enables interoperability of interfaces; reusable | Increases overall complexity of the code |
| Composite | Represents part-whole hierarchies of objects | When you want to treat individual objects and compositions of objects uniformly | Graphic drawing editor handling shapes and groups of shapes | Simplifies client code; easier management of objects | Design can become overly generalized |
| Proxy | Provides a placeholder for another object to control access to it | Lazy loading, logging, access control, smart reference | Internet proxy server controlling access to web content | Control object access; reduce cost of expensive operations | Can introduce a level of indirection; may impact performance |
| Flyweight | Minimizes memory usage by sharing as much data as possible with similar objects | When dealing with large numbers of similar objects with little variation in state | Characters in a word processor | Reduces memory usage; efficient data sharing | Complexity; managing shared state |
| Bridge | Separates an object’s abstraction from its implementation | When you want to avoid a permanent binding between an abstraction and its implementation | Different UI platforms with different backend renderers | Abstraction and implementation can vary independently; scalability | Increased complexity; conceptual overhead |
| Decorator | Adds responsibilities to objects dynamically | When extending capabilities of a class in runtime | Adding scrolling to a text view dynamically | More flexible than subclassing; avoid feature-loaded classes | Can lead to complex code structure; hard to debug |
| Facade | Provides a simplified interface to a complex subsystem | When there's a complex system and you want to provide a simple interface to it | Home theater control system | Simplifies interface; reduces dependencies on outside code | Can become a single point of failure; may limit flexibility |
Pattern taxonomy recap
| Family | What it solves | Canonical patterns |
|---|---|---|
| Creational | How objects are instantiated and who decides the concrete type | Singleton, Factory Method, Abstract Factory, Builder, Prototype |
| Structural | How classes/objects are composed into larger structures | Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy |
| Behavioral | How objects communicate and how responsibilities are distributed | Observer, Strategy, Command, State, Template Method, Iterator, Mediator, Memento, Chain of Responsibility, Visitor |
Structural patterns: when to use
| Pattern | Use when | Skip when |
|---|---|---|
| Adapter | You need to use an existing class with an incompatible interface | You own the target interface and can change it |
| Bridge | Abstraction and implementation must vary independently | There is only one implementation and no planned variation |
| Composite | You need to treat individual objects and compositions uniformly | The hierarchy is shallow and uniform by nature |
| Decorator | Add responsibilities dynamically without subclassing | A simple helper method or AOP is sufficient |
| Facade | You need a simplified interface to a complex subsystem | The subsystem is already simple or the facade hides too much |
| Flyweight | Many objects share most of their state | Object count is low or extrinsic state management is complex |
| Proxy | You need controlled access, lazy loading, or a remote stand-in | Indirection adds more confusion than value |
Interview trap box
- "Adapter vs Decorator confusion." Adapter changes the interface so an existing object can be used; Decorator keeps the same interface and adds behavior. Run the three-question test above.
- "Proxy is just a cache." Proxy controls access; caching is one of many possible responsibilities. Do not name the pattern from one use case.
- "Composite is only for trees." It is about part-whole hierarchies, not tree depth. A flat group-of-items can also use Composite.
- Over-using Facade. A facade that hides everything becomes a "god object" and makes the subsystem harder to test. Facade is optional; subsystem types stay reachable.
- Bridge when N=1. If abstraction and implementation will never vary independently, skip Bridge.
- Strategy vs State. Same structure (a context holding an interface), different force: Strategy is an interchangeable algorithm the client picks; State is behavior that changes as the object's own internal state transitions. If the object decides its own next behavior, it is State; if the caller decides, it is Strategy.
- Singleton as "global everything." Reaching for Singleton to hold a shared DB/config hides dependencies and blocks test doubles and multi-tenant instances. Prefer dependency injection; use Singleton only for genuinely single, stateless, lifecycle-free services.
Self-check
- Interface change? Always forward? May skip? Apply to logging middleware vs PayPal SDK bridge vs virtual proxy image loader.
- When does Facade become a god object, and how do you know?
🤖 Don't fully get this? Learn it with Claude
Stuck on Summary (2)? Open Claude, copy a block below, and it'll teach you this exact concept — visually and interactively.
🎨 Explain it visually
Build the mental picture, not memorization.
I just read a lesson on **Summary (2)** (OO & Low-Level Design) and want to truly understand it. Explain Summary (2) from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
🤔 Walk me through it (interactive)
Socratic — adapts to where you're stuck.
Teach me **Summary (2)** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
🧪 Quiz me & fix my gaps
Active recall exposes what you missed.
Quiz me on **Summary (2)** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
🧠 Make it stick
Intuition + hook + flashcards for long-term memory.
Help me remember **Summary (2)** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.