FACADE DESIGN PATTERN

Submitted By:
Naresh. V
SathiaMoorthy. M
Thamizhan. S
ThamizhSelvan. V
Contents
1. Contextual Forces
1.1 Motivation
1.2 Encapsulation
1.3 Procedural Analog
1.4 Non-Software Analog
2. Implementation Forces
2.1 Example
2.2 Questions, concerns, credibility checks
2.3 Options in implementation
2.4 "Strangling" a Legacy System
3. Consequent Forces
3.1 Testing issues
3.2 Cost-Benefit (gain-loss)
3.2.1 Facade and N-Tier Architectures
 Contextual Forces

Motivation
• Provide a simplified, improved, or more object-
oriented interface to a sub-system that is overly
complex (or may simply be more complex than is
needed for the current use), poorly designed, a
decayed legacy system, or otherwise inappropriate
for the system consuming it.
• Façade allows for the re-use of a valuable sub-system
without coupling to the specifics of its nature.
 Contextual Forces

Encapsulation
• The sub-system’s nature (complexity, design,
decay, OO/Procedural nature, etc...).
• Optionally, the presence of the sub-system
itself (see Questions, Concerns, Credibility
checks)
 Contextual Forces

Procedural Analog
• When creating large procedural systems, often we
will create a "gateway routine" as a sort of API that
allows the aggregation of many different parts of the
system into a single called routine.
• This "gateway" routine makes the system easier to
use, and is essentially the precursor to a Façade in an
object-oriented system. It it not strictly an analog, it
is in fact an early version of the pattern.
 Contextual Forces

Non-Software Analog
• A hotel concierge (at an upscale hotel) stands
between the hotel guest and all the various services
that are needed to make for a successful, satisfying
stay at the hotel.
• The guest has goals, which are expressed from the
guest's point of view. The concierge translates these
goals into needed interactions with the concrete
services needed to achieve them.
 Contextual Forces

Non-Software Analog(cont..)
• For example, the guest may say "we'd like to go out
to an evening dinner, and a show, and they return to
the hotel for an intimate dessert in our room".
• The concierge handles all the nitty-gritty details (a
taxi, restaurant reservations, theatre tickets,
housekeeping prep of the room, the kitchen
preparing the dessert, room-service delivery, etc...)
 Contextual Forces
Non-Software Analog(cont..)

THE CONCIERGE HERE IS THE FAÇADE ANALOG

 Implementation Forces
Example
 Implementation Forces
Example(cont…)
public class Facade {
public void m1() {
// make all calls into the existing system,
// hiding the complexity
}
public string m2() {
// make all calls into the existing system,
// converting the return
return rval;
}
}
 Implementation Forces
Questions, concerns, credibility checks
• Can we totally encapsulate the sub-system? The Façade can
be a convenience service or a constraining service.
• Convenience:' The System Under Development can "go
around" and use the existing sub-system directly for
infrequent, unusual, or orthogonal needs.
• This keeps the interface of the Façade relatively small and
cohesive, but couples the System Under Development to the
sub-system.
• The call marked "optional" in the diagram above shows this
behavior.
 Implementation Forces

Questions, concerns, credibility checks(cont…)

 Can we make the Façade stateless? Façades are often fairly
heavyweight and instantiating them can impact performance.
 Therefore, if they can be made stateless, they can be
implemented as Singletons, which alleviates the performance
and resounce impact of the Façade.
 Implementation Forces

Options in implementation
• Facade is often implemented using other patterns.
In fact, the Façade is not really a specific design, but
rather a role that is implemented in whatever way is
considered most appropriate given the forces in the
problem.
 Implementation Forces
For example, here is a Façade implemented using a Chain of Responsibility
 Implementation Forces
Options in implementation
• To keep a Façade stateless, often it is advisable to externalize the state
into a lightweight object:
 "Strangling" a Legacy System
• Imagine an old, very decayed, and poorly-implemented legacy
system. You've probably had to work with one or more of
these in your practice.
• We often think of them as a "big ball of mud" because they
are incomprehensible, brittle, and "dense":
 "Strangling" a Legacy System
(cont…)
• Job one is to stop using the system in the old way when
writing new code that has to interact with it. If we could, we'd
stop here and re-factor or rewrite the system entirely, but
often that is simply not an option: we have to live with it, at
least for now.
• However, using the old system directly (as the "legacy users"
do) will mean writing code that is similar in nature to the code
in the system, and at the very least we want our new code to
be clean, tested, and object-oriented. So, we create a Façade
with the interface we "wish we had" and then delegate from
there into the various routines in the legacy system. The
Facade, as mentioned below, can be mocked to make our new
code much more testable.
 "Strangling" a Legacy System
(cont…)
 "Strangling" a Legacy System
(cont…)
• Now that we have this in place, the "new users" can be developed more
cleanly and with higher quality.
• Now, over time, and without significant time pressure on the project, we
can incrementally pull out behaviors from the legacy system into more
clean, tested, object-oriented code, and delegate from the old routines
into the new ones:
 "Strangling" a Legacy System
(cont…)
 "Strangling" a Legacy System
(cont…)
 "Strangling" a Legacy System
(cont…)
• Once we reach the point that the legacy system
remains only as a series of delegation points, nothing
but a thin shell around the new behaviors, we can
begin to re-factor the legacy users to use the Façade
instead of the delegating routines in the older system.
• The Façade itself can also be refactored to use the
new code directly. Again, this can be done
incrementally, as time permits, without a lot of
pressure. Naturally, once all the legacy users and the
Façade no longer use the thin-shell legacy system, it
can be retired.
 "Strangling" a Legacy System
(cont…)
 Consequent Forces
Testing issues
• Façades are inherently difficult to test if (as is
common) the sub-systems they cover are hard
to test.
• However, the presense of the Façade makes
the System Under Development
fundamentally easier to test because the
Façade, once in place, can be Mocked to
eliminate unpredictable dependencies.
 Consequent Forces
Testing issues
 Consequent Forces
• Cost-Benefit (gain-loss)
• A Façade keeps the client system clean, reduces complexity
when accessing existing sub-systems, and can allow for the re-
use of valuable legacy systems in a new context, without
reproducing their problems. An Encapsulating Façade de-
couples the client system entirely from the sub-system, which
means the sub-systems can be swapped, eliminated, crippled,
etc... This allows for easy creation of
• Demo versions of software. A demo version of the Façade can
create stubbed-out behavior for the sub-system, and stand it
its place, allowing the "front end" system to be demonstrated
without the backend software/hardware present.
 Consequent Forces
Cost-Benefit (gain-loss) (Cont..)
• Crippled versions of software. A crippling Façade can create a
limited-functionality version of a system, which can easily be
upgraded to the full version by replacing the crippling Façade
with the full Façade.
• Testing. The Façade can be Mocked or Faked (see Testing
Issues above) making the client system testable, which would
otherwise be much more difficult.
• Training versions of software. Similar to Demos, a training
Façade can be used to create predictable scenarios for
training, while allowing the students to interact with the
"real" front end of the overall system.
 Consequent Forces
Facade and N-Tier Architectures
• Imagine we are working on an application with a 3-
tiered architecture (UI, Middle, Data), and we want
to work in a test-driven way. Unfortunately, our
teams are all blocked, because...
• UI Tier – "I can’t start until the middle tier is done,
they provide the interface for the services I will
consume."
• Middle Tier – "I can’t start until the data-layer is
done, because I need to access it in order to provide
services to the UI. I also need to know the
persistence schemas, etc..."
 Consequent Forces
Facade and N-Tier Architectures (Cont..)
• Data Layer – "I can’t start until I know what the data
needs are. Also, I am involved in day-to-day business,
which must always take priority over new
development. I'll get to it when I get to it."
We can use Façades to separate these layers.
The Façades (initially just stubs - interfaces with no
implementation, or implemented to throw
exceptions) will present an interface deemed ideal
to the consuming layer. Also, each Façade "Stub"
will be a mockable entity, and so the layers can be
test-driven.
 Consequent Forces
Facade and N-Tier Architectures (Cont..)
 Consequent Forces
Facade and N-Tier Architectures (Cont..)
• Later these stubs can be evolved into full-fledged
Facades given the implementation of the service
layer in each case when this becomes available.
• This means that teams do not have to wait for
dependencies to be ready, and in fact decouples
them from specifics for good and all.
• Note that the same test will pass when the stubs
evolves in each case, because the Facade itself can
be mocked, and sports the same interface as the stub
did.
Thank You