Facade Pattern

Overview

The problem it solves A subsystem grows into a dozen classes that must be called in the right order with the right arguments. Every caller learns that order, repeats it, and breaks when it changes. A facade is one class with a few high-level methods that do the coordination. Callers ask for the outcome they want; the facade knows the steps.

The pattern is a structural pattern from the Gang of Four book (Gamma, Helm, Johnson and Vlissides, *Design Patterns*, 1994). The facade adds no new capability. It makes what exists easier to reach and lets the subsystem change behind it.

What one facade call does The value of a facade is the sequence it hides. Placing an order means reserving stock, charging a card, scheduling a shipment, and undoing the reservation if the charge fails. Without the facade, each caller has to know that.

A runnable example The subsystem classes stay public and usable on their own. The facade only orchestrates them.

The failure path is the part callers most often get wrong. Putting it in the facade means it is written once and tested once.

A facade in the standard library Python's subprocess module is a small example. The docs recommend run() for every case it can handle: it runs a command, waits for it to finish and returns a CompletedProcess. Behind it sits Popen, the lower-level interface with pipes, polling and signals, which the docs point you to for advanced cases. Both are public. Most code only ever needs the simple one.

• subprocess.run() — Almost everyone — One call: start, wait, collect output
• subprocess.Popen — Code that needs control — Streams, timeouts, non-blocking checks

This is the shape to aim for: the facade is the recommended door, and the subsystem stays open for those who need it.

Facade next to its look-alikes | Pattern | Wraps | Changes the interface? | Intent | |---|---|---|---| | Facade | A subsystem of many classes | Yes, to a new simpler one | Make it easy to use | | Adapter | One class | Yes, to one the client already expects | Make it fit | | Proxy | One object, same interface | No | Control access to it | | Mediator | Peers that would otherwise talk to each other | Replaces peer-to-peer calls | Coordinate colleagues |

A facade points outward: it simplifies a subsystem for the world. A mediator points inward: it keeps a set of objects from depending on each other. Both centralize coordination, which is why they are confused.

What you will be able to do - Draw a facade in front of a subsystem and say which arrows exist and which do not. - Write a facade method that orders steps and undoes earlier ones on failure. - Decide when a facade is a convenience and when it should be the only public door. - Recognize a facade that has turned into a God object, and split it. - Contrast Facade with Adapter, Proxy and Mediator by intent.

Interview questions

• What is the difference between a Facade and an Adapter?
• Should callers still be allowed to use the subsystem classes directly?
• When does a Facade become an anti-pattern, and how do you fix it?
• Should a facade translate the exceptions its subsystem throws?
• How do you test code that uses a facade, and the facade itself?

More Low-Level Design topics

• Disk Space Manager
• Domain-Driven Design
• Don't Repeat Yourself (DRY)
• Elevator System
• Encapsulation
• Event Sourcing
• Factory Method Pattern
• Flyweight Pattern
• Fork/Join Framework
• Front Controller Pattern
• Go Fish
• Hexagonal Architecture