Adapter vs Decorator vs Proxy vs Facade

Published 21 October 2026

All four are a class that holds another object and calls it. Read their code without the class names and you often cannot tell which one you are looking at. That is not a failure of understanding. The four patterns are named for why the wrapper is there, not for what the code looks like.

Four everyday pictures, three of them from the LLD course:

• Adapter is the travel plug. Your charger has Indian pins, the wall in London has different holes. The plug changes the shape. It adds no power.
• Decorator is the add-ons on a dosa. It is still a dosa, served the same way, now with cheese, and then butter on top of that.
• Proxy is the clinic receptionist. You came to see the doctor. The receptionist decides if and when you get in, and answers "is my report ready?" without disturbing the doctor at all.
• Facade is the hotel reception. One desk in front of housekeeping, the kitchen, billing and the cab desk.

Three questions#

Ask these about any wrapper and you can name it:

1. Does the caller see a different interface from the object inside?
2. Is behaviour being added to each call?
3. Is access to the real object being controlled: whether, when, or how often it is called?

Then one more, for the facade: how many objects are behind it? Follow a single call through each one:

Adapter: change the shape#

The new gateway's SDK wants paise, names its method createCharge and replies with an object. Checkout already expects pay(rupees) returning a boolean. The adapter translates, and does nothing else:

interface PaymentGateway {
  pay(rupees: number): boolean
}
 
// The new vendor's SDK: paise, a different name, a different reply.
class PaytmSdk {
  createCharge(req: { paise: number }) {
    return { status: 'succeeded', paise: req.paise }
  }
}
 
class PaytmAdapter implements PaymentGateway {
  constructor(private sdk: PaytmSdk) {}
  pay(rupees: number) {
    const res = this.sdk.createCharge({ paise: rupees * 100 })
    return res.status === 'succeeded'
  }
}
 
const gateway: PaymentGateway = new PaytmAdapter(new PaytmSdk())
console.log(gateway.pay(500)) // true

The interface going in (createCharge) is different from the interface coming out (pay). That is the whole test for an adapter.

Decorator: same shape, more behaviour#

A decorator has the same interface as the thing it wraps, so it can wrap another decorator, and you can stack them in any order:

interface PaymentGateway {
  pay(rupees: number): boolean
}
 
class Razorpay implements PaymentGateway {
  pay(rupees: number) {
    console.log(`razorpay charged ${rupees}`)
    return true
  }
}
 
class WithLogging implements PaymentGateway {
  constructor(private inner: PaymentGateway) {}
  pay(rupees: number) {
    console.log(`pay ${rupees} started`)
    return this.inner.pay(rupees)
  }
}
 
class WithReceipt implements PaymentGateway {
  constructor(private inner: PaymentGateway) {}
  pay(rupees: number) {
    const ok = this.inner.pay(rupees)
    if (ok) console.log(`receipt for ${rupees} sent`)
    return ok
  }
}
 
const gateway = new WithLogging(new WithReceipt(new Razorpay()))
gateway.pay(500)
// > pay 500 started
// > razorpay charged 500
// > receipt for 500 sent

Every layer always calls the one inside it. A decorator adds something to the call. It does not decide whether the call happens.

Proxy: same shape, controls access#

A proxy also has the same interface, but its job is to stand in front of the real object and decide whether, when and how often the real one is used. The common kinds:

• Caching proxy: answers repeated questions itself.
• Lazy proxy: does not create the expensive real object until the first call.
• Protection proxy: checks permissions and refuses some calls.
• Remote proxy: looks like a local object, actually sends each call over the network (a gRPC client stub is one).

interface MenuSource {
  menu(restaurantId: string): string[]
}
 
class MenuApi implements MenuSource {
  calls = 0
  menu(restaurantId: string) {
    this.calls += 1 // a network call in real life
    return ['Masala dosa', 'Filter coffee']
  }
}
 
class CachedMenu implements MenuSource {
  private cache = new Map<string, string[]>()
  constructor(private real: MenuSource) {}
  menu(restaurantId: string) {
    const hit = this.cache.get(restaurantId)
    if (hit) return hit
    const fresh = this.real.menu(restaurantId)
    this.cache.set(restaurantId, fresh)
    return fresh
  }
}
 
const api = new MenuApi()
const menus: MenuSource = new CachedMenu(api)
menus.menu('udupi-42')
menus.menu('udupi-42')
menus.menu('udupi-42')
console.log(api.calls) // 1

Three calls went in, one reached the real API. The caller holds a MenuSource and has no idea a cache is there.

Decorator vs Proxy: the hardest pair#

Put WithLogging and CachedMenu side by side and the structure is identical: same interface, holds the real object, forwards the call. Three things separate them.

So the logging wrapper in the question at the top is a decorator: it adds a line and always calls through. Make it skip the call for amounts over a limit, or answer from a cache, and it becomes a proxy.

Caching is the famous borderline case. The original design patterns book lists caching as a job for a proxy, and that is the line this page draws. The decorator chapter in the LLD course wraps a price service in a cache and calls it a decorator, because the interface stays the same and a feature is added, and plenty of codebases name it that way too. Both readings are defensible. Retries sit on the same line. An interviewer cares much more that you can say what the wrapper is for, and why you picked the name, than that you pick the "right" label.

Facade: one simple door in front of many#

The facade is the odd one out. It does not wrap one object with the same interface. It puts a new, smaller interface in front of several objects, and gets the sequence right once:

class Inventory {
  reserve(item: string) { console.log(`reserved ${item}`) }
}
class Payments {
  charge(rupees: number) { console.log(`charged ${rupees}`) }
}
class Kitchen {
  send(item: string) { console.log(`kitchen: ${item}`) }
}
class Riders {
  assign(item: string) { console.log(`rider for ${item}`) }
}
 
class OrderFacade {
  constructor(
    private inventory = new Inventory(),
    private payments = new Payments(),
    private kitchen = new Kitchen(),
    private riders = new Riders(),
  ) {}
  place(item: string, rupees: number) {
    this.inventory.reserve(item) // always first
    this.payments.charge(rupees)
    this.kitchen.send(item)
    this.riders.assign(item)
  }
}
 
new OrderFacade().place('Masala dosa', 120)
// > reserved Masala dosa
// > charged 120
// > kitchen: Masala dosa
// > rider for Masala dosa

The facade chapter starts with the bug this prevents: one team charged first and reserved second, and customers paid for dishes that had just sold out.

Adapter vs Facade is the other pair that gets mixed up, because both change the interface. An adapter makes one object fit an interface the caller already has. A facade invents a new, simpler interface over many objects. The adapter is about fitting, the facade is about hiding.

All four in one table#

The same ideas show up one level up, between machines. A reverse proxy, a load balancer and an API gateway are proxies and facades for whole services. That is in forward proxy vs reverse proxy vs API gateway.

In the interview#

Checkpoint#