A logical subsystem (the design of a component system) exports only a subset of its types, classes and other work products to re-users. The remaining work products are hidden. This separation insulates a re-user from the specific details of how a component system is implemented, and allows internal changes without necessarily impacting the re-user.

If the subsystem is modeled formally then this separation of interface from implementation is modeled using separate facade and implementation packages.

The facades thus encapsulate the internals of the subsystem in order to minimize dependencies, and rippling change, as the subsystem evolves. Each façade acts as a kind of public interface to the subsystem.

The façade is the re-user's view of the subsystem.  It simplifies the job for re-users who wish to use the subsystem (and therefore the components) presented by the façade.

The formal modeling of subsystems is used when:

• There are many dependencies between clients and the implementation classes of an abstraction.  Facades are introduced to de-couple the subsystem from clients, and other subsystems, thereby promoting subsystem independence and portability.
• You want to layer your subsystems.  Use a façade to define an entry point to each subsystem level.  If subsystems are dependent, then you can simplify the dependencies between them by making them communicate with each other solely through their facades.

The formal modeling of subsystems offers the following benefits:

• It shields clients from the implementation details of subsystems/components, thereby reducing the number of objects that clients deal with and making the subsystem easier to use
• It provides a simple, intuitive way of modeling subsystems and their implementations.
• It promotes weak coupling between the subsystem and its clients. Often the components in a subsystem are strongly coupled. Weak coupling lets you vary the components of the subsystem without affecting the clients.
• It helps layer a system and manage the dependencies between objects.  This can be an important consequence when the client and the subsystems are implemented independently.
• When modeling the subsystem's clients only the Façade needs to be loaded into the client model.

When a subsystem is defined formally then the subsystem's interface is defined in a different package to the implementation of the subsystem.  The interface is defined in a <<facade>> package (see Standards: Facade Package) and the implementation of the subsystem is defined in an <<implementation>> package (see Standards: Implementation Package). 

When this pattern is adopted the consumer of the subsystem only needs to import the <<facade>> package and any other packages upon which the <<facade>> package is dependent.  The implementation packages are not required when designing and documenting the client systems.

When subsystems are modeled formally the following diagramming standards are applied to the subsystem package itself.  See Standards: Facade Package and Standards: Implementation Package for details of the diagramming standards to applied to the facade and implementation packages.

Applying the Pattern

Examples

This definition of the façade pattern is a specialization of the definitions presented by the Unified Modeling Language [UML] and the classic Design Patterns book [DP].

The UML definition of <<façade>> (stereotype of package) is:

A stereotyped package containing nothing but references to model elements owned by another package. It is used to provide a public view of some of the contents of a package. A façade does not contain any model elements of its own i.e. a package that is only a view on some other package.

The Design Patterns definition of the façade pattern is:

The façade pattern provides a uniform interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use.

The only real difference between the UML definition and the definition used here is that in this definition the façade is used to define the interface of a subsystem and can contain, as well as import, the model items making up the interface.

This definition of the Façade pattern draws upon the following references: