facade design pattern

8/7/2019 FACADE DESIGN PATTERN

1/32

FACADE DESIGN PATTERN

Submitted By:

Naresh. VSathiaMoorthy. M

Thamizhan. S

ThamizhSelvan. V


2/32

Contents

1. Contextual Forces1.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 System3. Consequent Forces

3.1 Testing issues

3.2 Cost-Benefit (gain-loss)

3.2.1 Facade and N-Tier Architectures


3/32

Contextual Forces

Motivation

Provide a simplified, improved, or more object-

oriented interface to a sub-system that is overlycomplex (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.

Faade allows for the re-use of a valuable sub-system

without coupling to the specifics of its nature.


4/32

Contextual Forces

Encapsulation

The sub-systems nature (complexity, design,

decay, OO/Procedural nature, etc...).

Optionally, the presence of the sub-system

itself (see Questions, Concerns, Credibility

checks)


5/32

Contextual Forces

Procedural Analog

When creating large procedural systems, often we

will create a "gateway routine" as a sort of API thatallows 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 Faade in an

object-oriented system. It it not strictly an analog, it

is in fact an early version of the pattern.


6/32

Contextual Forces

Non-Software Analog

A hotel concierge (at an upscale hotel) stands

between the hotel guest and all the various servicesthat 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.


7/32

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 tothe 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...)


8/32

Contextual Forces

Non-Software Analog(cont..)

THE CONCIERGE HERE IS THE FAADE ANALOG


9/32

Implementation Forces

Example


10/32


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;

}

}


11/32


Questions, concerns, credibility checks

Can we totally encapsulate the sub-system? The Faade 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 Faade relatively small and

cohesive, but couples the System Under Development to thesub-system.

The call marked "optional" in the diagram above shows this

behavior.


12/32


Questions, concerns, credibility checks(cont)

Can we make the Faade stateless? Faades 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 Faade.


13/32


Options in implementation

Facade is often implemented using other patterns.

In fact, the Faade is not really a specific design, butrather a role that is implemented in whatever way is

considered most appropriate given the forces in the

problem.


14/32


For example, here is a Faade implemented using a Chain of Responsibility


15/32


Options in implementation To keep a Faade stateless, often it is advisable to externalize the state

into a lightweight object:


16/32

"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":


17/32

"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, atleast 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 newcode tobe clean, tested, and object-oriented. So, we create a Faade

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.


18/32


(cont)


19/32


(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 moreclean, tested, object-oriented code, and delegate from the old routines

into the new ones:


20/32


(cont)


21/32


(cont)


22/32


(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 Faade

instead of the delegating routines in the older system.

The Faade itself can also be refactored to use the new

code directly. Again, this can be done incrementally, astime permits, without a lot of pressure. Naturally, once

all the legacy users and the Faade no longer use the

thin-shell legacy system, it can be retired.


23/32


(cont)


24/32

Consequent Forces

Testing issues

Faades are inherently difficult to test if (as is

common) the sub-systems they cover are hard

to test.

However, the presense of the Faade makes

the System Under Development

fundamentally easier to test because theFaade, once in place, can be Mocked to

eliminate unpredictable dependencies.


25/32

Consequent Forces

Testing issues


26/32


27/32

Consequent Forces

Cost-Benefit (gain-loss) (Cont..)

Crippled versions of software. A crippling Faade can create a

limited-functionality version of a system, which can easily be

upgraded to the full version by replacing the crippling Faade

with the full Faade.

Testing. The Faade 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 trainingFaade can be used to create predictable scenarios for

training, while allowing the students to interact with the

"real" front end of the overall system.


28/32

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 cant start until the middle tier is done,

they provide the interface for the services I will

consume." Middle Tier "I cant 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..."


29/32

Consequent Forces

Facade and N-Tier Architectures (Cont..)

Data Layer "I cant start until I know what the data

needs are. Also, I am involved in day-to-day business,

which must always take priority over newdevelopment. I'll get to it when I get to it."

We can use Faades to separate these

layers. The Faades (initially just stubs - interfaces

with no implementation, or implemented to throwexceptions) will present an interface deemed ideal

to the consuming layer. Also, each Faade "Stub"

will be a mockable entity, and so the layers can be

test-driven.


30/32

Consequent Forces



31/32

Consequent Forces


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 stubsevolves in each case, because the Facade itself can

be mocked, and sports the same interface as the

stub did.


32/32

Thank You

facade design pattern

Documents