Design Pattern: Facade

1
Design Pattern Facade
Wei-Tek Tsai Department of Computer Science and
Engineering Arizona State University Tempe, AZ
85287
2
Intent

• Provide a unified interface to a set of
  interfaces in a subsystem
• Define a higher-level interface that makes the
  system easier to use.

3
Motivation

• Structuring a system into subsystems helps reduce
  complexity
• A common design goal is to minimize the
  communication and dependencies between
  subsystems.
• One way to achieve this goal is to introduce a
  facade object that provides a single, simplified
  interface to the more general facilities of a
  subsystem.

4
(No Transcript)
5
Applicability

• When you want to provide a simple interface to a
  complex subsystem. This will provide a simple
  default view of the subsystem that is good enough
  for most clients.
• When there are many dependencies between clients
  and the implementation classes of an abstraction.
  This will promote subsystem independence and
  portability.
• When you want to layer your subsystems.

6
Participants

• Façade
• knows which subsystem classes are responsible for
  a request
• delegates clients requests to appropriate
  subsystem objects
• subsystem classes
• implement subsystem functionality
• handle work assigned by the Façade object
• have no knowledge of the façade that is, they
  keep no references to it.

7
Collaborations

• Clients communicate with the subsystem by sending
  requests to Façade, which forwards them to the
  appropriate subsystem object(s).
• Although the subsystem objects perform the actual
  work, the façade may have to do work of its own
  to translate its interface to subsystem
  interfaces.
• Clients that use the facade dont have to access
  its subsystem objects directly.

8
Consequences

• Façade shields clients from subsystem components,
  thereby reducing the number of objects that
  clients deal with and making the subsystem easier
  to use.
• It promotes weak coupling between the subsystem
  and its clients. This allow you to vary the
  components of the subsystem without affecting its
  clients.
• It doesnt prevent applications from using
  subsystem classes if they need to.

9
About Implementation

• Consider following issues when implementing a
  façade
• Reducing client-subsystem coupling.
• One approach is to make Façade an abstract class.
  Different implementations are just different
  concrete subclasses.
• Public versus private subsystem classes
• Façade is part of the public interface, which all
  clients have access
• Private interface is just for subsystem
  extenders.

10
(No Transcript)
11
Sample Code
class Scanner public Scanner(istream) virt
ual Scanner() virtual Token Scan() private
istream _inputStream class
Parser Public Parser() virtual
Parser() virtual void Parse(Scanner,
ProgramNodeBuilder)
12
Class ProgramNodeBuilder public ProgramNodeBuil
der() virtual ProgramNode NewVariable( char
variableName ) const virtual ProgramNode
NewAssignment( ProgramNode variable,
ProgramNode expression ) const virtual
ProgramNode NewReturnStatement( ProgramNode
value ) const virtual ProgramNode
NewVariable( ProgramNode condition, truePart,
falsePart ) const // ProgramNode
GetRootNode() private ProgramNode _node
13
class ProgramNode public ... virtual void
Add(ProgramNode) virtual void
Remove(ProgramNode) // class
CodeGenerator public virtual void
Visit(StatementNode) virtual void
visit(ExpressionNode) protected CodeGenerat
or(BytecodeStream) BytecodeStream _output
14
Class Comipler public Compiler() virtual
void Compile(istream BytecodeStream) void
CompilerCompile(istream input, BytecodeStream
output) Scanner scanner(input) ProgramNodeBuil
der builder Parser parser parser.Parse(scanne
r, builder) RISCCodeGenerator
generator(output) ProgramNode parseTree
builder.GetRootNode() parseTree-gtTravese(generat
or)