Facade

Pattern Properties

Type: Structural

Level: Component

Purpose

To provide a simplified interface to a group of subsystems or a complex subsystem.

Introduction

Users like to be able to modify a GUI to make it more visually appealing or usable. For example, some users might have a visual impairment and have trouble reading a small font, so they need to increase the font size. Forcing the user to step through all the setup screens, (in the current small font size), wading through the modem and printer and scanner settings until reaching the setup options needed, wouldn’t be very user friendly. A wizard, which would be designed for helping the visually impaired do setup, would be much better.

This kind of help should not limit the options to use and customize the application. Instead, you want to provide a specialized view of the system, and at the same time keep all the other features. This kind of a Facade pattern is a front end, or wizard, for the system.

Applicability

Use Facade to:

Make complex systems easier to use by providing a simpler interface without removing the advanced options.

Reduce coupling between clients and subsystems.

Layer subsystems by providing Facades for sets of subsystems.

Description

Most modern software systems are fairly complex. Design patterns help you structure applications and better deal with the complexity. They often accomplish this by dividing functionality among a series of smaller classes. Additional classes can also be produced as a result of system partitioning. Dividing a system into several subsystems helps you deal with complex systems and provides the opportunity to partition the work.

Dividing a system into a number of specialized classes is a good object-oriented design practice. However, having a large number of classes in a system can be a drawback as well.

Clients using that system have to deal with more objects. Users tend to become confused when presented with hundreds of configuration options. Car manufacturers, among others, recognize this and adapt their products accordingly; for instance, when was the last time you had to set the air/gas ratio inside your car engine? Doing that every time you start your car is not practical. What you want is that you would only have to insert the car key and turn it to start the car (or actually the car engine). The rest should be handled for you. A client benefits from having only a few basic options. A Facade can provide these options and can then determine which subsystems to call.

Normally the Facade will delegate most of the work to the subsystems, but it can do some work itself.

Note that it is not the intent of a Facade to hide the subsystems. The intention is to provide a simpler interface to a set of subsystems, but clients who need the more elaborate options can still interact with the subsystems.

A setup wizard is one example of a Facade.

Implementation

The Facade object diagram is shown in Figure 3.7.

120

Figure 3.7. Facade object diagram

Implement the following for Facade:

Facade – The class for clients to use. It knows about the subsystems it uses and their respective responsibilities. Normally all client requests will be delegated to the appropriate subsystems.

Subsystem – This is a set of classes. They can be used by clients directly or will do work assigned to them by the Facade. It does not have knowledge of the Facade; for the subsystem the Facade will be just another client.

Y L The benefit of the Facade pattern is that it provides a simpleFinterface to a complex system without reducing the

options provided by the total system. This interface protectsMthe client from an overabundance of options. A The Facade translates the client requests to theEsubsystems that can fulfill those requests. Most of the time, one

request will be delegated to more than oneTsubsystem. Because the client interacts only with the Facade, the internal working of the system can change, while the client to the Facade can remain unchanged.

The Facade promotes low coupling between client and subsystems. It can also be used to reduce coupling between subsystems. Every subsystem can have its own Facade and other parts of the system use the Facade to communicate with the subsystem.

Pattern Variants

Pattern variants include the following:

You can implement the Facade as an interface or an abstract class. This leaves the implementation details to a later time. It also reduces coupling.

Several Facades can provide different interfaces to the same set of subsystems.

The Facade pattern is sometimes varied in order to hide the subsystems. When the Facade pattern is used at the boundary between systems in an architecture, one of its goals is to reduce the complexity of system-system interaction. For instance, a system where calls pass through a central facade is more maintainable than one with a large number of cross-coupled classes).

Related Patterns

Related patterns include the following:

TEAM FLY PRESENTS

121