Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
• The Façade Design Pattern (1)
– A structural design pattern
• Decouples interface from implementation
– Intent
• To provide a unified interface to a set of
interfaces in a subsystem
• To simplify an existing interface
• Defines a higher-level interface that makes
the subsystem easier to use
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
• The Façade Design Pattern (2)
– Problem
• Situation I: Wish to simplify a process for most
clients
–
–
–
Subsystems are built for multiple applications
Most applications use only a small subset
Most applications interact in a predefined manner
• Situation II: Wish to reduce the number of
dependencies between client and implementation
classes
–
Requires an interface that allows a level of
isolation
• Situation III: Wish to build a layered software
design with all inter-layer communication between
interfaces
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
• The Façade Design Pattern (3)
– Non-software example
Customer Service Representative
–
Provides a unified interface to each of the
departments involved in a transaction
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
• The Façade Design Pattern (4)
– Abstract Description
• Object Design Pattern
Client
Client
Client
• Most clients use façade to achieve desired
results
–
Façade can be bypassed for more complex access
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
• The Façade Design Pattern (5)
– Consequences
• Shields clients from subsystem
complexity
• Promotes weak coupling between clients
and subsystems
– Easier to swap out alternatives
• Allows more advanced clients to bypass and have direct subsystem access
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
• The Façade Design Pattern (6)
– Implementation Issues
• Can involve nontrivial manipulation of subsystem
–
–
May require several steps in sequence or
composition
May require temporary storage
• Can completely hide subsystem
–
–
–
Place subsystem and façade in package
Make façade only public class
Can be difficult if subsystem objects returned
to client
• Can implement Façade as abstract class
–
Allows different concrete facades under same
interface
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
• The Façade Design Pattern (7)
– Example: Tic-Tac-Toe
• When a player wants to make a move it must
tell:
–
–
–
the “board” to make such a move
the “control manager” to set up for next
turn (halt the game, skip a turn, change
players, …)
The “view administrator” to announce the
winner, loser, or draw if the game is over
• To avoid this complication, player interacts
with a single interface IGame (the façade)
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
• The Façade Design Pattern (8)
– Example: Tic-Tac-Toe
public abstract class APlayer {
protected IGame game;
public APlayer(IGame g, …){
this.game = g;
Handles all the details.
…
}
}
public class ComputerPlayer extends APlayer {
…
public void takeTurn() {
…
getGame().takePosition(p.x, p.y, this, …);
}
}
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
• The Façade Design Pattern (9)
– Second Example: Data Access Object
• Data Access Object
• Data Manager
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
• The Façade Design Pattern (10)
– Common Variations
• Key: Don’t add new behavior, just simplify
interface to existing behavior
– Java API Usage
• java.net.URL
–
–
client can use it without being aware of
classes that allow it to work
client can use classes like URLConnection
directly if they choose
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
• The Façade Design Pattern (11)
– Adapter & Façade are often compared
Facade
Adapter
Are there preexisting classes?
Yes
Yes
Is there an interface we must design to?
No
Yes
Does an object need to behave
polymorphically?
No
Probably
Is a simpler interface needed?
Yes
No
• Common misperception
–
Façade deals with multiple classes and
Adapter deals with one
• Adapter converts an interface and façade
simplifies one