System Design ( Day - 53 )

Facade Design Pattern

Definition
Facade pattern provides a simplified, unified interface to a set of complex subSystem and exposes only what is necessary.

Example
When you’ve got a bunch of subsystems to juggle—power, BIOS, CPU, memory, OS—you don’t want every client in your codebase calling them all in the right order. You also want to make sure each module only “knows” the parts it absolutely needs. Enter:

1. The Facade Pattern – a simple front-door to hide complexity

2. The Principle of Least Knowledge (Law of Demeter) – talk only to your direct friends

---

🔍 The Problem

Imagine booting a computer. You need to:

• Turn on the PowerSupply

• Spin up CoolingSystem fans

• Initialize the CPU

• Run Memory self-tests

• Spin up the HardDrive

• Let the BIOS boot (using CPU & Memory)

• Load the OperatingSystem

If every caller had to know this exact sequence and each subsystem’s interface, your code would become a tangled mess.

---

🛠️ The Facade Pattern

Goal: Provide a single class (ComputerFacade) that:

• Hides all those boot-up steps

• Orchestrates calls to each subsystem in the correct order

• Gives clients one simple method: startComputer()

UML Overview

Benefits:

• Simplicity: Clients see just one method.

• Decoupling: Subsystems can evolve without breaking every caller.

• Readability: High-level intent shines (“startComputer”), not low-level wiring.

🤝 Principle of Least Knowledge

Even within your facade or any class, you shouldn’t reach into far-away objects. The Law of Demeter says a method M in object A should only call:

1. Methods of A itself

2. Methods of objects passed into M

3. Methods of objects M creates

4. Methods of A’s direct components (its has-a fields)

Why? Minimizing “strangers” you talk to makes your code less coupled and easier to refactor.

Real World example

1. While loading games.

2. Payment gateways.