Card 02/ 08
Facade Pattern Structure: The Class Diagram
One Facade class in front of many subsystem classes, which do not know it exists.
Facade has three participants: the client, the facade, and the subsystem classes that do the work. This card reads each role off the Gang of Four's class diagram, and points at the two arrows the diagram leaves out, which matter as much as the ones it draws.
| Participant | Role |
|---|---|
| Facade | Knows which subsystem classes a job needs and calls them in order, passing results between them. |
| Subsystem classes | Do the real work, and have no reference to the facade. |
| Client | Calls the facade for the common jobs, and may still use a subsystem class directly. |
Every arrow points away from the client. No arrow runs from a subsystem class back to the facade, so the subsystem works without it and can be used and tested on its own. No line forbids the client from reaching a subsystem class either: the diagram shows the usual path, and the subsystem's classes remain public for the client that needs more control than the facade offers.
There is no interface in the diagram. A facade is usually one concrete class, because its job is to simplify, not to be swapped. When a test needs to replace it, an interface can be extracted then.
Nor is a subsystem limited to one facade. A video library might offer one facade for converting files and another for reading their metadata, each with the few methods its clients need, over the same subsystem classes. Two small facades stay simpler than one that tries to serve every client.
← → move through sections and cards