Structural Design Patterns: Four Wrappers, Four Intents

A design pattern is a named, reusable answer to a problem that keeps coming back in code. The 1994 Gang of Four book sorted its 23 patterns into three families. Creational patterns are about making objects. Structural patterns are about how objects connect. Behavioral patterns are about how objects talk. The design patterns page maps all three.

Structural patterns change how pieces are put together without changing what each piece does. Very often the tool is a wrapper. A wrapper is an object that holds another object and stands between it and the caller. Every call goes to the wrapper first, and the wrapper decides what to pass on.

That shared shape is why four of these patterns get confused. Proxy, Adapter, Decorator and Facade can look almost the same in code. The Proxy lesson's answer is to look at intent: why are you wrapping this object?

All four wrap something. The lesson's comparison sorts them by two questions. Does the wrapper keep the same interface? And what is it for?

• Proxy keeps the same interface and controls access. It decides whether the call happens at all. On a cache hit, the real object is never called.
• Adapter changes the interface to bridge two systems that do not fit. Your code calls processPayment(amount, currency, cardToken). The Razorpay SDK wants initiateTransaction() with a differently shaped object. The adapter translates, including rupees to paise. See the Adapter Pattern lesson.
• Decorator keeps the same interface and stacks new behavior. A logging wrapper and a retry wrapper go around an HttpClient, and every layer runs and passes the call on. Express middleware works this way. See the Decorator Pattern lesson.
• Facade creates a new, simpler interface over a complex subsystem. The client calls MediaPlayer.play(file), and the facade drives the video decoder, audio decoder and subtitle parser in the right order. See the Facade Pattern lesson.

The classic interview question is how Proxy differs from Decorator, since both keep the interface. The lesson's answer: a proxy controls access, as in should this call happen, or is the result cached? A decorator adds function, such as logging, retries or metrics. In real systems the line blurs. An Envoy sidecar proxy caches, controls access and adds behavior at once. Name the intent and you will rarely be wrong.

The Proxy lesson lists when a wrapper pays for itself:

• You need cross-cutting behavior, such as caching, auth, logging or rate limiting, without editing the original class.
• The real object is expensive to create or reach, such as a remote service or a large file.
• You want access control without changing client code.
• You need to intercept traffic transparently, as service meshes and CDNs do.

And when it does not. A wrapper that adds nothing is just one more hop. Each proxy hop adds some latency, which the lesson puts at about 0.1 to 0.5 ms. A caching proxy without an invalidation plan serves stale data, which trades correctness for speed. Invalidation means removing or updating a cached copy when the real data changes.

Order matters when wrappers stack. The Decorator lesson shows the trap. If auth runs before the cache, unauthorized users never see cached data. If the cache runs first and its key ignores who the user is, one user can be served another user's cached response.

Proxies sit next to the patterns that build objects, which are covered in creational design patterns. To step through a cache hit and a cache miss in one proxy, and the layered proxy stack, the Proxy Pattern lesson is the next step.