Playing a movie takes an amplifier call, a volume call, a projector call, an input-mode call, and a player call, in that order, and every screen in the app that plays movies performs the whole ritual itself. Facade is the Gang of Four structural pattern that puts one simple, goal-shaped interface in front of a tangled subsystem, what the catalog describes as a front-facing interface masking more complex underlying code, named for the architectural front of a building.
A facade is really just the class that knows the order of operations so nobody else has to. It owns no behavior of its own, it sequences calls into objects that do, and its one structural promise is easy to miss: the subsystem behind it stays public. Callers who need the raw dials walk around the front desk, and the pattern is fine with that.
Here's the failure in miniature. A home theater has three subsystem classes, and two different screens play movies: one reached from the menu, one from search. Each rebuilt the setup sequence from memory, and memory is exactly as reliable as it sounds. Compare the two functions line by line and find what search forgot:
The search path never calls set_input("hdmi"), so it returns playing Inception (volume 5, no signal), a movie playing into a blank projector. Nothing crashes, every individual call succeeded, and the bug lives purely in the choreography. With two call sites this gets caught in review. With a real subsystem's six or eight steps across a dozen screens, some copy of the ritual is wrong right now in a codebase near you.
The facade version moves the choreography into a single class. HomeTheater holds the three subsystem objects and exposes one verb, watch(title), whose body is the ritual written once, in the right order, reviewed once. Both screens collapse to one call. Before reading past the code, predict the output and notice what the last line of the example is allowed to do:
It prints playing Inception (volume 5, hdmi), correct from every call site forever, because there's exactly one copy of the sequence to keep correct. The last line is the part worth dwelling on: theater.amp.set_volume(11) reaches past the facade and twists a subsystem dial directly. That reach-around is deliberate: the facade simplifies the common case without making the uncommon case impossible.
The cast has two roles, and the asymmetry between them is the pattern. The Facade (HomeTheater) knows every subsystem class, holds references to them, and sequences their methods into goal-shaped verbs. The subsystem classes (Amplifier, Projector, MediaPlayer) know nothing about the facade, and that one-way ignorance is load-bearing: the subsystem can be developed, tested, and reused as if the facade didn't exist.
The pattern works like a hotel concierge. One call gets you dinner reservations, and the concierge coordinates the restaurant, the car, and the doorman, none of whom you ever speak to. The analogy has a limit worth keeping: at a good hotel the concierge is optional, and a guest who wants to negotiate with the kitchen directly may. A facade that forbids direct subsystem access has become a wall, and walls collect doors cut into them one emergency at a time.
Installing the pattern is four moves:
watch(title), not configure_av_pipeline(). One goal-level verb per client intention, each hiding however many subsystem calls the goal requires.watch() there are only calls to subsystem objects, in the right order, with the right arguments. The moment the facade grows logic of its own, it has started becoming a subsystem, which is the failure mode with its own name.Facade is the one structural pattern that's organizational rather than mechanical, and both languages express it with visibility instead of classes. In Go, the package boundary is the facade boundary: a package exports a handful of high-level functions while its subsystem types stay unexported, and the front door is whatever the capital letters say it is. The struct version in the code tab works identically when the subsystem spans packages.
Rust does the same with module visibility. A module exposes a small pub surface while internals stay pub(crate) or private, and the compiler enforces what the GoF could only recommend. The interesting difference is the default: in both languages the door-not-wall advice inverts, because the natural move is to hide everything, and the discipline is remembering to leave the subsystem reachable when callers legitimately need it.
You might think Facade is Adapter scaled up, and the two do share a job description of standing between your code and something awkward. Two questions separate them cleanly. How many things stand behind it: an adapter fronts one class, a facade fronts a subsystem of many. And who chose the interface: an adapter implements an interface the client already demands, while a facade invents a new, simpler one nobody demanded but everybody wanted. A wrapper matching TemperatureSource is an adapter, and watch(title), an interface that existed nowhere until the facade coined it, is the other thing.
The same counting separates Facade from the wrapper patterns generally: decorators and proxies preserve the interface of the single object they hold, while a facade neither preserves an interface nor holds a single object. If you can swap the wrapper in where the original went, you are not looking at a facade.
Facades fail by succeeding. The front door is convenient, so the next feature gets a method on it, then the next, and business logic starts settling into the facade because it's the class everyone already imports. A few quarters later the facade knows everything, touches everything, and tests like a tar pit, which is the god object anti-pattern assembled from helpful contributions. The tell is logic that exists only in the facade: real orchestration delegates every decision, so a facade you can't delete without losing behavior has stopped being one.
The repair is splitting by audience and re-delegating: playback screens get a playback facade, admin tools get an admin facade, and whatever logic accumulated gets pushed down into the subsystem where it belonged. The subsystem doesn't mind. It never knew the facade existed.
The pattern is one class and a discipline, and the discipline is most of it:
watch("Inception") tells a reader everything, while initSubsystemsAndPlay() leaks the plumbing into the name. If a facade method's name needs the word "and", it's probably two client goals sharing one method.Two questions before you go. First: the search screen shipped a blank projector. What does the facade version change about where that class of bug can live, and who has to keep it fixed? Second: Facade and Adapter both stand in front of other code, so what two countable questions tell them apart? Both answers are on this page, the second in its own section.
Then go spot it in the wild, starting with the one that says so on the label: SLF4J, the Simple Logging Facade for Java, one logging interface fronting log4j, logback, or java.util.logging, swappable at deployment time. Client libraries that hide raw wire protocols behind three friendly methods are the same move. Last, look at your own codebase for the function colleagues describe as "the helper that sets everything up". That function is a facade that hasn't been given its name yet, and naming it is how the ritual stops being folklore.
class Amplifier:
def __init__(self):
self.volume = 0
def set_volume(self, level: int) -> None:
self.volume = level
class Projector:
def __init__(self):
self.source = "no signal"
def set_input(self, source: str) -> None:
self.source = source
class MediaPlayer:
def play(self, title: str) -> str:
return "playing " + title
def play_from_menu(title: str) -> str:
amp = Amplifier()
projector = Projector()
player = MediaPlayer()
# The setup ritual, performed correctly here
amp.set_volume(5)
projector.set_input("hdmi")
return player.play(title) + " (volume " + str(amp.volume) + ", " + projector.source + ")"
def play_from_search(title: str) -> str:
amp = Amplifier()
projector = Projector()
player = MediaPlayer()
# Same ritual, rebuilt from memory: the projector step got lost
amp.set_volume(5)
return player.play(title) + " (volume " + str(amp.volume) + ", " + projector.source + ")"
# Example usage
print(play_from_menu("Inception")) # playing Inception (volume 5, hdmi)
print(play_from_search("Inception")) # playing Inception (volume 5, no signal)class Amplifier:
def __init__(self):
self.volume = 0
def set_volume(self, level: int) -> None:
self.volume = level
class Projector:
def __init__(self):
self.source = "no signal"
def set_input(self, source: str) -> None:
self.source = source
class MediaPlayer:
def play(self, title: str) -> str:
return "playing " + title
class HomeTheater: # Facade: one front door to the whole subsystem
def __init__(self):
self.amp = Amplifier()
self.projector = Projector()
self.player = MediaPlayer()
def watch(self, title: str) -> str:
# The ritual, written once, in the right order
self.amp.set_volume(5)
self.projector.set_input("hdmi")
return self.player.play(title) + " (volume " + str(self.amp.volume) + ", " + self.projector.source + ")"
# Example usage: every screen in the app is now one call
theater = HomeTheater()
print(theater.watch("Inception")) # playing Inception (volume 5, hdmi)
# The subsystems stay reachable; the facade is a door, not a wall
theater.amp.set_volume(11)