Design Patterns: FacadeBlog

Software Design Patterns: Facade

post-thumb

Introduction

This post gives a brief overview about the Facade Pattern. The post is part of a series about software design patterns and their UML representations with the help of PlantUML.

The article aims at providing a very short description of the general idea of the pattern in the first part. This also involves a descriptive UML diagram. Then, the second part provides the PlantUML code for the diagram so that these posts can also be used as a source of design patterns in PlantUML syntax.

What is the Facade Pattern?

A facade can:

  • make a software library easier to use, understand, and test, since the facade has convenient methods for common tasks
  • make the library more readable, for the same reason
  • reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system
  • wrap a, subjectively, poorly-designed collection of APIs with a single well-designed API

Implementors often use the facade design pattern when a system is very complex or difficult to understand because the system has a large number of interdependent classes or because its source code is unavailable. This pattern hides the complexities of the larger system and provides a simpler interface to the client.

What problems can the Facade design pattern solve?

  • To make a complex subsystem easier to use, a simple interface should be provided for a set of interfaces in the subsystem.
  • The dependencies on a subsystem should be minimized.

Clients that access a complex subsystem directly refer to (depend on) many different objects having different interfaces (tight coupling), which makes the clients hard to implement, change, test, and reuse.

What solution does the Facade design pattern describe?

Define a Facade object that

  • implements a simple interface in terms of (by delegating to) the interfaces in the subsystem and
  • may perform additional functionality before/after forwarding a request.

This enables to work through a Facade object to minimize the dependencies on a subsystem.

UML Diagram

The following diagram shows the Facade Pattern in UML notation. It is based on the corresponding chapter in the book “Head First Design Patterns”:

Facade Pattern

You can click on the diagram to open it online in Pladitor.

Diagram Sources

Here are the diagram sources:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
@startuml

skinparam Ranksep 20
hide empty fields
hide empty methods

class Client
class Facade
Client --> Facade

package "Subsystem Classes" {

    note "More complex\nsubsystem" as n1

    Facade - "class 1"
    Facade - "class 2"

    package "class 1" {
    }

    package "class 2" {
    }

    package "class 3" {
    }

    package "class 4" {
    }

    package "class 5" {
    }

    package "class 6" {
    }

    "class 1" -- "class 2"
    "class 1" -- "class 3"
    "class 2" -- "class 4"
    "class 3" -- "class 5"
    "class 3" -- "class 6"
    "class 4" -- "class 5"
    "class 4" -- "class 6"
}

note left of Client
Happy client whose
job just became
easier because of
the facade.
end note

note right of Facade
Unified interface
that is easier to use.
end note
@enduml

Open this diagram online with Pladitor.

Share: