Design Patterns: Proxy PatternBlog

Introduction

This post gives a brief overview about the Proxy 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 Proxy Pattern?

According to Wikipedia, a proxy, in its most general form, is a class functioning as an interface to something else. The proxy could interface to anything: a network connection, a large object in memory, a file, or some other resource that is expensive or impossible to duplicate. In short, a proxy is a wrapper or agent object that is being called by the client to access the real serving object behind the scenes. Use of the proxy can simply be forwarding to the real object, or can provide additional logic.

What problems can the Proxy design pattern solve?

The Proxy pattern aims for solving:

• The access to an object should be controlled.
• Additional functionality should be provided when accessing an object.

When accessing sensitive objects, for example, it should be possible to check that clients have the needed access rights.

What solution does the Proxy design pattern describe?

Define a separate Proxy object that

• can be used as substitute for another object (Subject) and
• implements additional functionality to control the access to this subject. This enables to work through a Proxy object to perform additional functionality when accessing a subject. For example, to check the access rights of clients accessing a sensitive object.

To act as substitute for a subject, a proxy must implement the Subject interface. Clients can’t tell whether they work with a subject or its proxy.

UML Diagram

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

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

@startuml

hide empty fields

interface Subject {
{abstract} request()
}
together {
class RealSubject
class Proxy
}

RealSubject : request()
Proxy : request()

Subject <|.. RealSubject
Subject <|.. Proxy
RealSubject <- Proxy : subject

note bottom of RealSubject
The RealSubject is
usually the object
that does most
of the real work;
the Proxy controls
access to it.
end note

note “The Proxy often instantiates\nor handles the creation of\nthe RealSubject.” as n1

RealSubject .. n1
Proxy .. n1

note right of Subject
Both the Proxy and the
RealSubject implement the
Subject interface. This
allows any client to treat
the proxy just like the
RealSubject.
end note
@enduml

Open this diagram online with Pladitor.