Design Patterns and Frameworks – Facade

(1)

Design Patterns and Frameworks – Facade

Oliver Haase

Oliver Haase Emfra — Facade 1/10

(2)

Description

I Classification: Object-based structural pattern

I Purpose: Provides a homogeneous interface to a set of interfaces of a subsystem. Simplifies usability of the subsystem.

(3)

Motivation

(4)

Motivation

(5)

Motivation

Problem: Client has to know a lot of classes /interfaces to simply watch a movie

→many dependencies, tight coupling, hard to change home theater configuration without the need to change all clients

(6)

Motivation

(7)

Description

I Applicability: Use the facade pattern to

I hide a subsystem’s internal complexity and provide a simplified interface to clients. Systems tend to grow over time, design patterns tend to increase the number of classes. A facade shields clients from that complexity.

I loosen coupling between the subsystem and clients. A facade removes dependencies from the actual subsystem classes.

I build multi-layered architecures, separated through one facade per layer as the entry point for the next higher layer.

(8)

Structure

(9)

Participants

I Facade:

I knows which subsystem classes are responsible for which requests

I delegates client requests to respective subsytem objects

I Subsystem:

I implements the subsystem functionality

I executes requests from the facade

I do not know the facade, i.e. do not have reference to facade object→strict layering

(10)

Interactions

I Clients use the subsystem by sending requests to the facade.

The facade forwards the request to the responsible subsystem objects(s). One client request might well lead to several subsystem requests. Even though the subsystem functionality is implemented in the subsystem, the facade might “fill in”

some logic to orchestrate the lower level requests.

I Clients that use the facade do not have to use the subsystem directly.