Java Reference
In-Depth Information
didn't have spaghetti code, but we had more layers than a meat lasagna. We were
quite happy in our little world—that was, until other teams started to use our core
services. Very soon, both the performance of the system and our ability to handle
change requests started to suffer.
We contracted a famous and expensive consultant from one of our server vendors
to analyze our system. He had a few meetings, spent some time browsing our code
base, and concluded that some refactoring was in order, so he deleted all façades
and related interfaces. The result was that we had less code to maintain and much
better performance, so everyone was happy. The moral of this story is to use
patterns—even the simple ones—sparingly and only when you need them, and
dei nitely don't show off your knowledge of patterns.
Façade Class Diagram
As can be seen in the class diagram in Figure 3-1, the façade pattern provides a simple interface to
an underlying system. It encapsulates the complicated granular logic.
Client
<<EJBSession>>
SessionFacade
BusinessObject
1..*
accesses
<<EntityEJB>>
BusinessEntity
<<SessionEJB>>
BusinessSession
accesses
accesses
DataAccessObject
FIGURE 3-1
Class diagram of the façade pattern
IMPLEMENTING THE FAÇADE PATTERN IN PLAIN CODE
Implementing the façade pattern isn't complicated. It doesn't enforce a strict structure or rule set.
Any method that provides easy access to a complicated l ow could be considered an implementation
of the façade pattern.
Now you'll implement the washing machine example given in the introduction as shown in
Listing 3-1. You need two methods—
heavilySoiled
and
lightlySoiled
—that represent the two
washing modes. All complicated work (the selection of water temperature, spin cycle duration,
decision to add bleach or not) is performed in methods invoked from within the façade.
