Java Reference
In-Depth Information
WHAT IS A FAÇADE?
The GoF
1
book describes this pattern as “providing a unii ed interface to a set of interfaces in a
subsystem.”
Head First Design Patterns
2
gives the same explanation and points out that, while
hiding the complexity of the subsystem, the façade pattern offers the full power of the subsystem via
an easier‐to‐use interface.
To give a basic real‐world example of how the façade pattern works, imagine a washing machine
with only two wash modes: heavily soiled and lightly soiled. For each mode, the washing machine
must execute a predei ned set of operations: set water temperature, heat water, set duration of wash
cycle, set duration of spin cycle, add detergent, add bleach, add fabric softener, and so on. Each
mode requires a different set of washing instructions (different amounts of detergent, higher or
lower temperature, longer or shorter spin durations, and so on).
The simple interface provides two wash modes that hide the complicated logic of selecting the
appropriate water temperature, the duration of the spin and wash cycle, and the different methods
for adding detergent, bleach, or fabric softener. The user of the washing machine does not have
to think about the complicated logic of how to wash the clothes (decide the temperature, cycle
duration, and so on). The only decision the user must make is whether the clothes are heavily soiled
or lightly soiled. This is in essence the façade pattern applied to a washing machine design. Later on
in this chapter, you will see an implementation of this use case.
The façade pattern is commonly implemented for the following purposes and situations:
➤
Provide a simple and unii ed access to a legacy back‐end system.
➤
Create a public API to classes, such as a driver.
Offer coarse‐grained access to available services. Services are combined, such as in the
washing machine example.
➤
Reduce network calls. The façade makes many calls to the subsystem, while the remote client
makes only one call to the façade.
➤
➤
To encapsulate l ow and inner details of an app for security and simplicity.
NOTE
Façades are sometimes implemented as singleton abstract factories.
WAR STORY
In the early dark days of J2EE, I was working as a junior developer for a huge
banking application where we implemented almost all the J2EE design patterns.
All Enterprise JavaBeans (EJB) were wrapped by a façade, and every service EJB
using that façade was wrapped with another façade. We also had interfaces for the
façades to ensure we didn't break the API. In J2EE, EJB needs a local and remote
interface, so writing one EJB meant writing four interfaces and two classes. We
