Exercises — Design Patterns — Structural - Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy

Adapter. Fingerprint: an existing, unchangeable class whose method names don't match what the client speaks, so you build a translator. The client wants read(); the adaptee offers parse_xml(); your wrapper implements read() and forwards to parse_xml(). The clue words are "cannot edit" + "signatures differ" + "translate".

Proxy (a caching proxy). Same interface + forwards calls — that alone matches both Proxy and Decorator. The deciding word is control access: the wrapper decides whether to call the real service at all (cache hit ⇒ skip it). A Decorator would always call the inner object and add behaviour around the result, never suppress the call. Here the point is access control, so it is a Proxy.

Bridge. Two independent hierarchies — abstraction (shapes) and implementation (renderers) — joined by a reference so each can grow without the other. Fingerprint: designed up front to stop an $m\times n$ class explosion, giving $m+n$ classes instead.

Build it:

root = Folder()
root.add(File(10))
root.add(File(25))
sub = Folder()
sub.add(File(5))
root.add(sub)
print(root.size())   # -> 40

Why 40? root.size() sums its children uniformly: File(10).size()=10, File(25).size()=25, and sub.size() recurses into its one child File(5).size()=5. Total $10+25+5=40$. The key: Folder.size() never checks whether a child is a leaf or another folder — Recursion plus a shared interface does all the work. See the tree in the figure below.

Peel the wrappers from the inside out — each layer calls the inner one first, then adds its bit: $\text{Coffee}=2.0\to \text{Milk}=2.0+0.5=2.5\to \text{Sugar}=2.5+0.2=2.7\to \text{Milk}=2.7+0.5=3.2$ Answer: 3.2. Note that Milk appears twice and each application adds $0.5$ independently — that stackability is exactly the Decorator payoff. The figure shows the nesting as onion layers.

"banana" has 6 characters but only 3 distinct letters: b, a, n.

• Intrinsic (shared) objects created: 3 — one Glyph per distinct character. The a object is reused for all three as, n for both ns.
• Extrinsic positions passed: 6 — one (x, y) per character drawn, because every letter sits somewhere different.

The whole win of Flyweight: memory scales with distinct intrinsic values (3), not with total usages (6).

The Facade's job was to enforce a correct ordering and hide it. Splitting it exposes four steps whose order matters, and now every caller must remember freeze → load → read → jump. Any caller who reorders them gets a broken boot. The lost guarantee is orchestration: the subsystem's usage protocol is no longer encapsulated in one place. This violates the Single Responsibility Principle indirectly — the responsibility "know the correct boot sequence" got scattered across every client — and it undermines the whole reason for a Facade, which is to give one simple, correct-by-construction door to a complex subsystem.

• Inheritance (class explosion): $m\times n=5\times 4=20$ classes.
• Bridge (composition): $m+n=5+4=9$ classes.
• Adding one new color: inheritance needs one new subclass per shape → $+m=+5$ classes (total $25$). Bridge needs one new Color class → $+1$ (total $10$).

The gap $mn$ vs $m+n$ widens fast; this is precisely the combinatorial explosion Bridge prevents by letting the two dimensions vary independently (a Composition over Inheritance win, and directly the Open-Closed Principle: extend by adding, not editing).

Second identical call: Logging.handle(req) logs "incoming", then forwards to Cache.handle(req). Cache finds the request in its store from the first call and returns the cached value without ever touching Service. Logging logs "outgoing" and returns.

• Cache is a Proxy because it controls access: it decides whether the real Service runs at all (skipped on a cache hit).
• Logging is a Decorator because it adds a responsibility (recording) but always forwards; it never suppresses the inner call.

Same interface, same wrap-and-forward shape — separated purely by intent: access control vs added behaviour.

Two patterns, cleanly separated:

• Adapter for the legacy player (translate play → open_flac).
• Decorator for stackable effects (each shares the play interface, adds behaviour, forwards).

class Player:                       # Target interface
    def play(self, file): ...
 
class Flac:                         # Adaptee (legacy, unchangeable)
    def open_flac(self, path): print("flac:", path)
 
class FlacAdapter(Player):          # ADAPTER
    def __init__(self, legacy): self._legacy = legacy
    def play(self, file): self._legacy.open_flac(file)
 
class Effect(Player):               # DECORATOR base: wraps a Player, IS a Player
    def __init__(self, inner): self.inner = inner
class VolumeBoost(Effect):
    def play(self, file):
        print("+volume"); self.inner.play(file)
class FadeIn(Effect):
    def play(self, file):
        print("+fade"); self.inner.play(file)
 
# Compose freely — no combination classes:
p = FadeIn(VolumeBoost(FlacAdapter(Flac())))
p.play("song.flac")

Why this split works: the Adapter makes the legacy class speak the target interface, so the Decorators — which require every layer to share that interface — can wrap it exactly like any native player. Adapter solves the compatibility problem; Decorator solves the combinatorial-effects problem. Neither knows about the other. This is Composition over Inheritance doing double duty and honouring the Open-Closed Principle.

class TreeFactory:
    _pool = {}
    def get(self, kind):
        if kind not in self._pool:
            self._pool[kind] = TreeModel(kind)   # heavy, created once
        return self._pool[kind]                  # shared instance
 
def draw_tree(model, x, y, scale):               # extrinsic passed in
    ...

Heavy TreeModel objects in memory: 3 — one per distinct kind, regardless of the million placements. The per-tree (x, y, scale) is lightweight extrinsic state stored in a plain list, so memory scales with distinct models (3), not with instances ($10^6$). That is the entire point of Flyweight: share the heavy invariant part.

No — it has become a Proxy + Decorator hybrid, and that mixing is the smell.

• The caching / access-control behaviour (deciding whether to hit the real service) is genuine Proxy intent.
• Modifying the returned value by prepending text is adding a responsibility to the output — that is Decorator intent.

A pure Proxy returns the subject's result unchanged; the moment it alters the payload it is decorating. The clean fix is to split them: a CachingProxy for access control wrapped by a separate LoggingDecorator for the string change — restoring Single Responsibility Principle and making each layer independently testable and removable.

Why the summary is true: each pattern holds a reference to another object and forwards work to it (composition) — Adapter forwards+translates, Decorator forwards+adds, Proxy forwards+gates, Facade forwards to many, Composite forwards to a collection, Bridge forwards across a dimension, Flyweight forwards to a shared instance. Structurally, they are one idea. This is why Composition over Inheritance and Dependency Inversion underpin the whole family. Why it is dangerous alone: because the code shape is identical, shape can never tell you which pattern you need. Picking a pattern requires reading the problem's intent — mismatch? extension? access control? explosion prevention? memory sharing? simplification? A student who reasons only from shape will name whichever pattern they saw last, and get it wrong exactly when it matters (as in 5.1). The summary compresses knowledge; it does not replace intent analysis.