Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
"Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to user." (Gamma, E., R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995)
Structuring a system into subsystems helps reduce complexity. A common design goal is to minimize the communication and dependencies between subsystems. One way to achieve this goal is to introduce a façade object that provides a single, simplified interface to the more general facilities of a subsystem. Consider for example a programming environment that gives applications access to its compiler subsystem. This subsystem contains classes such as Scanner, Parser, ProgramNode, BytecodeStream, and ProgramNodeBuilder (Subsystem Class in the thumbnail) that implement the compiler. Some specialized applications might need to access these classes directly. But most clients of a compiler generally dont care about details like parsing and code generation; they merely want to compile some code. For them, the powerful but low-level interfaces in the compiler subsystem only complicate their task. To provide a higher-level interface that can shield clients from these classes, the compiler subsystem also includes a Compiler class (Façade in the thumbnail). This class defines a unified interface to the compilers functionality. The Compiler class acts as a façade: It offers clients a single, simple interface to the compiler subsystem. It glues together the classes that implement compiler functionality without hiding them completely. The compiler façade makes life easier for most programmers without hiding the lower-level functionality from the few that need it.
This pattern has been used on the following systems: The ET++ application framework allows an application to have built-in browsing tools for inspecting its objects at run-time. The browsing tools are implemented in a separate subsystem that includes a Façade class called "ProgrammingEnvironment." This façade defines operations such as InspectObject and InspectClass for accessing the browsers. If the application does not use built-in browsing support, ProgrammingEnvironment will implement the requests as null operations. (Weinand, A., E. Gamma, and R. Marty. ET++--An object-oriented application framework in C++. In Object-Oriented Programming Systems, Languages, and Applications Conference Proceedings, pp. 46-57, San Diego, CA, September 1988, ACM Press.) Facades are used in the Choices operating system to compose many frameworks into one. Choices has as key abstractions: processes, storage, and address spaces. Each abstraction has a corresponding subsystem, implemented as a framework, that supports porting Choices to a variety of different hardware platforms. (Campbell, R.H., N. Islam, D. Raila, and P. Madeany. Designing and implementing Choices: An object-oriented system in C++. Communications of the ACM, 36(9):117-126, September 1993.)
Abstract Factory, Mediator, and Singleton patterns
Abstract Factory pattern, Singleton pattern, Facade pattern, Mediator pattern, structural patterns, Gamma patterns, forward requests, interface (high-level), subsystem (entire), subsystem (complex)
any system integrated with multiple, disparate systemsany system providing layers to abstract complexity
need to layer subsystemsneed to provide abstraction between subsystem and client
may reduce compilation dependenciespermits clients of various skills to access the appropriate layer of the systempromotes layering of systemsprovides weak coupling between clients and subsystems
Test driver Test.javaSimple implementation of the pattern - Subsystem3 class. Subsystem3.javaSimple implementation of the pattern - Subsystem2 class. Subsystem2.javaSimple implementation of the pattern - Subsystem1 class. Subsystem1.javaSimple implementation of the pattern - Facade class. Facade.javaTest driver testfacade.cppSimple implementation of the pattern. facade.h