Structural Design Patterns
Facade Design Pattern
7/1/2016
CS 631: Facade Pattern
1
Outline
Application
– Short Selling
– Trading Subsystems
• Account management
• Transaction management
• Valuation
• Facade Pattern
– Design
– Analysis
– Implementation
• Structural Design Patterns
– Definition
7/1/2016
CS 631: Facade Pattern
2
Short Selling
• This trade (AKA "shorting") involves selling an asset
that is not owned.
• Example on a short sale of shares of stock:
– An investor instructs a broker to short 500 IBM shares.
– A broker borrows the shares from another client and sells
them in the open market.
– The investor can maintain the short position as long as
desired, provided there are always shares for the broker to
borrow.
– At some stage, the investor closes out the position by
purchasing 500 IBM shares.
– These are replaced in the account from which they were
borrowed.
7/1/2016
CS 631: Facade Pattern
3
Short Selling (cont.)
• The investor takes profit if the stock price has
declined, and the loss otherwise.
• If the broker runs out of shares to borrow, the investor
is short-squeezed and is forced to close out the
contract immediately.
• An investor must pay to the broker any income, such
as dividends or interest.
– Assume the IBM share's price was $120 at the start of
shorting, and $100 at the end. During the contract a $1
dividend was paid. The investor's net gain is
• 500  $120 - $500 – 500  $100 = $9,500
7/1/2016
CS 631: Facade Pattern
4
Trading Subsystems
• Consider an application that implements various
functions of trading. It may have the following
subsystems.
– Account managing:
• Open/close/find an account for a client;
• Add/remove/transfer assets;
• Credit/debit funds.
– Transactions managing:
• Find parties for a trade;
• Execute a trade.
– Valuation
• Evaluate a deal's value according to current market's conditions.
7/1/2016
CS 631: Facade Pattern
5
Trading Subsystems: Design
7/1/2016
CS 631: Facade Pattern
6
Short Selling: Implementation
// Find an investor to borrow assets from
AccountManager amgr(...);
Asset asset(...);
Investor investor = // find the investor;
amgr.remove(asset,...);
// Evaluate and execute the trade
Deal deal(asset, ...);
Valuation val(...);
double price = val.evaluate(deal);
if // price is OK
{
TransactionsManager tmgr(...);
vector<Investor> investors =
tmgr.find(deal);
// update accounts of investors
}
...
7/1/2016
CS 631: Facade Pattern
7
Short Selling: Analysis
• In order to implement a short selling strategy a
substantial amount of code needs to be written.
– The user would need to know too many details about trading
subsystems, their interface and how they interact with each
other.
– The short selling algorithm can be packaged in a class.
• However, implementing another strategy could again involve
substantial effort.
• Solution: implement a class that exposes essential
details of trading subsystems:
– Open position
– Close position
– Execute a deal
7/1/2016
CS 631: Facade Pattern
8
Trading Facade
7/1/2016
CS 631: Facade Pattern
9
Facade Design Pattern: Analysis
• Intent
– Provide a unified interface to a set of interfaces in a
subsystem.
• Applicability
– To provide a simple interface to a complex subsystem.
• Subsystems often get more complex as they evolve.
– When there are many dependencies between clients and the
implementation classes of an abstraction.
• A facade decouples the subsystem from clients and other subsystems.
– To layer subsystems.
• Use a facade to define an entry point to each subsystem level.
7/1/2016
CS 631: Facade Pattern
10
Facade Pattern Analysis: Participants
• Participants
– Facade (Trading)
• knows which subsystem classes are responsible for a request.
• delegates client requests to appropriate subsystem objects.
– Subsystem classes (AccountManager, TransactionManager,
Valuation)
• implement subsystem functionality.
• handle work assigned by the Facade object.
• have no knowledge of the facade, i.e. keep no references to it.
7/1/2016
CS 631: Facade Pattern
11
Facade Pattern Analysis: Benefits
• Shields clients from subsystem components, thereby
reducing the number of objects the clients deal with.
• Promotes weak coupling between the subsystem and
its clients.
– It allows one to vary the components of the system without
affecting the clients.
– Facades help layer a system and avoid circular
dependencies.
• It does not prevent applications from using subsystem
classes if they need to.
– One can choose between ease of use and generality.
7/1/2016
CS 631: Facade Pattern
12
Facade Pattern Analysis: Implementation
• Reducing client-subsystem coupling.
– Facade can be made an abstract class with concrete
subclasses for different implementations of the subsystem.
– An alternative is to configure a Facade object with different
subsystem objects.
• Public versus private subsystem classes.
– The public interface of the subsystem consists of classes that
all clients can access.
• The Facade class is a part of public interface, but it's not the only
part.
• Making other classes of the subsystem private.
– Can be done in C++ by using namespaces.
7/1/2016
CS 631: Facade Pattern
13
Structural Design Patterns
• Structural patterns are concerned with how classes and
objects are composed to form larger structures.
– Structural class patterns use inheritance to compose
interfaces or implementations.
• For example, multiple inheritance mixes two or more classes into
one.
– Structural object patterns describe ways to compose objects
to realize new functionality.
• For example, Composite pattern describes how to build hierarchy of
objects.
• Facade pattern shows how to make a single object represent an entire
subsystem.
7/1/2016
CS 631: Facade Pattern
14