Facade Pattern

Some jobs take several classes, called in the right order, with the right values passed from one to the next. When every client repeats that sequence, every client depends on every class in it, and a change to one of them reaches all of them. The Facade pattern puts one class in front of the subsystem with a few methods for the common jobs, so most clients call one method and know one class.

This topic opens on that problem and the pattern's intent, then reads the participants off the class diagram, where the subsystem does not know the facade exists and stays public. The template shows one facade method calling three subsystem classes in Python, Java and TypeScript.

Two examples follow: placing an order across stock, payment and shipping, where the facade also undoes a reservation when a payment fails, and Python's subprocess.run, one call over the process machinery in Popen. The gotcha is a facade that keeps growing until it holds the logic its subsystem was meant to hold, and the exercise writes a facade for a home cinema.

By the end you can recognise a facade, and say what a client can still reach behind it.