The Facade pattern is straightforward in concept, though its implications connect to deeper principles like the Law of Demeter. Before examining the pattern itself, it’s worth noting that this discussion follows the Adapter pattern and precedes the Proxy pattern. A later chapter will address the subtle differences and relationships among Adapter, Facade, Proxy, and Decorator patterns, which are often conflated.
Understanding the Problem
Consider a system composed of many interconnected classes. These classes interact in complex ways: one class uses another, which in turn depends on a third, while a fourth class maintains bidirectional relationships with several others. The diagram may show arbitrary connections, but the essential point is that substantial complexity exists in how these components relate to one another.
Now introduce a client—not a customer, but rather a piece of code that needs to use these components. In software design, “client” refers to code that consumes another piece of code. This client needs to interact with multiple parts of the system in specific ways to accomplish its goals.
Such complexity often arises in well-designed systems. A highly decoupled architecture naturally leads to many classes, each adhering to the Single Responsibility Principle. When each class performs exactly one task, the system inevitably contains numerous small, focused components. This granularity is beneficial: it promotes maintainability and flexibility. However, it introduces a practical challenge. To accomplish any meaningful work, client code must orchestrate many classes simultaneously, and this orchestration can become intricate.
Consider the compiler example from the Gang of Four’s Design Patterns: Elements of Reusable Object-Oriented Software. A compiler comprises components like scanners, parsers, tokens, and symbol tables. Structuring the system with separate classes for each responsibility makes architectural sense. The high level of abstraction and separation is justified. Yet actually compiling a program requires coordinating all these pieces, which can quickly become unwieldy.
The wiring required to set up these relationships may be non-trivial. Suppose class A depends on class B, and B is injected as a dependency. To instantiate A, you must first instantiate B. But if B requires C, and C needs a reference back to B, the initialization sequence becomes more elaborate. You might construct B, then construct C without arguments, set C on B, and then set B on C to establish the bidirectional relationship. Depending on the scenario, the initialization logic grows complex.
This complexity is not inherently problematic. Highly decoupled systems are desirable, and intricate setup procedures are often a natural consequence of generality. Because components are so general and composable, they can be arranged in many configurations to achieve diverse outcomes. The trade-off is that configuring them requires careful attention.
The Facade Solution
The Facade pattern provides a way to manage this complexity. It acknowledges that intricate wiring is sometimes necessary but offers an easier way to perform it. The metaphor of a building facade is apt. A facade is the exterior face of a building. The building requires far more than its facade to function—plumbing, electrical wiring, insulation, foundation, and roof are all essential. Yet residents interact primarily with the facade, not with the internal infrastructure. They don’t want to see the plumbing; they want a clean, simple interface to the building.
The Facade pattern applies this same principle to software. Beneath the facade lies substantial plumbing—all the complex interactions among classes. Outside, client code interacts with a single, simplified interface that handles the complexity internally. The facade performs all the intricate wiring, whether that involves classes A, B, C, or any other combination.
In structural terms, the client interacts with the facade, and the facade invokes methods on multiple other classes, which may themselves invoke methods on still more classes. This is not the Composite pattern, which will be covered separately. There is no inherent order or recursive structure to the subsystem behind the facade. The relationships depend entirely on the specific domain and requirements. Some dependencies flow one direction, others flow another. The key is that the facade encapsulates these interactions and presents a simplified interface to clients.
When multiple clients need to perform the same complex interaction, it makes sense to interact with a single facade rather than duplicating the intricate logic across the codebase. Whenever you introduce an interface that clients use instead of directly managing a collection of complex components, you are essentially applying the Facade pattern.
The Law of Demeter
The Facade pattern relates closely to the Law of Demeter, also known as the Principle of Least Knowledge. This principle can be summarized as “talk only to your immediate friends”—objects should interact only with their direct collaborators, not with the collaborators of their collaborators.
Coupling is undesirable because it makes change difficult. If class X couples to class Y, and Y couples to class Z, changes to Z may ripple through Y and ultimately affect X. When a class representing a person couples to a class representing a pen, changes to the pen’s behavior may force changes to the person class if the new behavior is incompatible with prior assumptions. The ideal remains low coupling and high cohesion.
The Law of Demeter attempts to reduce coupling by restricting which method calls are permissible. A simplified version of the rule states: you may call a.b(), but you may not call a.b().c(). In other words, you may talk to objects you know directly, but not to objects returned by those objects. You may talk to your friends, but not to friends of your friends.
This restriction has consequences. If class A needs something from class C, but only knows class B (which knows C), then B must act on behalf of C. This may require B to expose a broader interface, effectively proxying C’s functionality. Whether this indicates that B has taken on too much responsibility is a matter of debate.
The more precise formulation from Design Patterns specifies that within a method, you may only invoke methods on:
- The object itself
- Objects passed as parameters to the method
- Objects created within the method
- Instance variables (components) of the object
This definition is more rigorous than the informal “no chaining” rule. There is ongoing discussion about whether the Law of Demeter relates more to type relationships than to call chains, and whether its application always improves design or sometimes forces artificial indirection.
Definition and Summary
The formal definition from Head First Design Patterns states: The Facade pattern provides a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
The facade does not add functionality; it simplifies access. It sits at a higher level of abstraction, shielding clients from the complexity of the subsystem beneath. Rather than interacting with numerous interrelated classes, clients interact with a single facade that manages those interactions on their behalf.