The Facade

Intent: Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher level interface that makes the subsystem easier to use (Gamma et al., 1994).

Example: When planning a vacation, business trip, or other travel, there are a lot of different aspects that has to be reserved, scheduled, and otherwise arranged for. Each of these elements (a hotel, a rental car, etc.) has a different way of accessing them. In the past, this would involve a lot of phone calls, the use of a legacy system called Saber, some faxes, etc. People often preferred to use a travel agent to handle all of these details.

Conceptually, a travel agent is a facade: one person to deal with who hides all the complexity of the various interactions involved. They may even do things that we do not know are needed. Today, there are web-based services that do the same, and they are also an example of the facade pattern. They present a single interface that encapsulates all of the varying interfaces involved.

Figure 8: Facade example diagram.

Qualities and Principles: The facade decouples all clients from the various interfaces and types that it encapsulates, and how those types are designed and created. The interface of the facade is not based on any service implementation, but on the general needs of the clients that use it. The facade separates the concerns of use from all other concerns, simplifying and focusing clients.

Testing: The facade itself can be mocked, making the testing of all clients fundamentally simpler and faster. Testing the facade itself depends on the nature of the elements it encapsulates—how they are designed.

Questions and Concerns: Facades can end up being fairly heavyweight in terms of their memory footprint and instantiation time, so it is usually best if multiple instances of the facade are not needed. This means the facade should not become specialized for a particular client, and thus should contain no client-specific state. A flyweight (see p. 32) can be used to prevent this, and making the facade a singleton (see p. 48) can enforce that there is only one facade created. Once the facade interface is created, adapters (see p. 18) can be used for varying client needs.

Facades are often used when developing new code that has dependencies on legacy code. If a facade is introduced between new development and legacy, then the legacy nature (which may be highly procedural and/or low quality) does not influence/pollute new work. Facades also make legacy refactoring less risky.

For more information: https://tinyurl.com/y5x6kzos