Design Patterns & RefactoringFacade

Oliver Haase

HTWG Konstanz

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 1 / 10

Description

Classification: Object-based structural pattern

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

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 2 / 10

Motivation

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 3 / 10

Motivation

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 4 / 10

Motivation

Problem: Client has to know a lot of classes /interfaces to simply watch amovie→ many dependencies, tight coupling, hard to change home theaterconfiguration without the need to change all clients

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 5 / 10

Motivation

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 6 / 10

Description

Applicability: Use the facade pattern to

hide a subsystem’s internal complexity and provide a simplifiedinterface to clients. Systems tend to grow over time, design patternstend to increase the number of classes. A facade shields clients fromthat complexity.loosen coupling between the subsystem and clients. A facade removesdependencies from the actual subsystem classes.build multi-layered architecures, separated through one facade per layeras the entry point for the next higher layer.

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 7 / 10

Structure

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 8 / 10

Participants

Facade:

knows which subsystem classes are responsible for which requestsdelegates client requests to respective subsytem objects

Subsystem:

implements the subsystem functionalityexecutes requests from the facadedo not know the facade, i.e. do not have reference to facade object →strict layering

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 9 / 10

Interactions

Clients use the subsystem by sending requests to the facade. Thefacade 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 thesubsystem, the facade might “fill in” some logic to orchestrate thelower level requests.

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

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 10 / 10