# Facade

> Provide a simple, focused interface over a complex subsystem — clients call the Facade and don't need to understand what's happening under the hood.

- **Category**: Software Design
- **Subcategory**: structural
- **Canonical URL**: https://designpattern.fyi/patterns/facade/

---

## Description
**Intent**: Hide subsystem complexity behind a simple interface so clients only deal with what they actually need.

**Context**: You're integrating a complex library — a video processing pipeline, a cloud storage SDK, a payment processing system — that has dozens of classes and initialization steps. Client code shouldn't need to know about all of that.

**Solution**: Create a Facade class that exposes a simple, high-level API covering the operations clients actually need. Internally it orchestrates the complex subsystem. Clients use the Facade; power users who need more control can still access the subsystem directly.


## Use Cases
Use when you want to provide a simple interface to a complex subsystem for the common use cases — third-party library wrappers, SDK abstractions, service layer APIs.



## Implementation Example

```javascript
class CPU {
  freeze() { console.log("CPU Freezing"); }
  jump(position) { console.log(`Jumping to ${position}`); }
  execute() { console.log("Executing..."); }
}

class Memory {
  load(position, data) { console.log(`Loading ${data} to ${position}`); }
}

class ComputerFacade {
  constructor() {
    this.cpu = new CPU();
    this.memory = new Memory();
  }
  start() {
    this.cpu.freeze();
    this.memory.load(0x00, "OS Boot Sector");
    this.cpu.jump(0x00);
    this.cpu.execute();
  }
}

```



## Trade-offs


### Advantages

- Clients are shielded from subsystem complexity — just call the Facade.




### Considerations & Drawbacks

- Facade can accumulate responsibilities and become a God Object that knows too much about the entire system.







---
**Reference**: [Original Source](https://refactoring.guru/design-patterns/facade)

