Proxy design pattern

Proxy Design pattern
Control the access to your objects

Motivation
 The need to control the access to a certain object

Intent
 The Proxy pattern provides a surrogate or placeholder for another
object to control access to it
 This ability to control the access to an object can be required for a
variety of reasons:
 To hide information about the real object to the client

 To perform optimization like on demand loading
 To do additional house-keeping job like audit tasks
 Proxy design pattern is also known as surrogate design pattern

Context
Sometimes a client object may not be able to access a service provider
object (also referred to as a target object) by normal means. This could
happen for a variety of reasons depending on:

 The location of the target object
 The target object may be present in a different address space in the same or a
different computer.

 The state of existence of the target object
 The target object may not exist until it is actually needed to render a service or
the object may be in a compressed form.

 Special Behavior
 The target object may offer or deny services based on the access privileges of its
client objects. Some service provider objects may need special consideration
when used in a multithreaded environment

Solution
In such cases, the Proxy pattern suggests using a separate object referred to
as a proxy to provide a means for different client objects to access the target
object in a normal, straightforward manner.
 The Proxy object offers the same interface as the target object.
 The Proxy object interacts with the target object on behalf of a client
object and takes care of the specific details of communicating with the
target object
 Client objects need not even know that they are dealing with Proxy for the
original object.

 Proxy object serves as a transparent bridge between the client and an
inaccessible remote object or an object whose instantiation may have
been deferred.

Implementation
 UML class diagram for the Proxy Pattern

Implementation
The participants classes in the proxy pattern are:
 Subject - Interface implemented by the RealSubject and representing its
services. The interface must be implemented by the proxy as well so that
the proxy can be used in any location where the RealSubject can be
used
 Proxy
 Maintains a reference that allows the Proxy to access the RealSubject.
 Implements the same interface implemented by the RealSubject so that the
Proxy can be substituted for the RealSubject.
 Controls access to the RealSubject and may be responsible for its creation and
deletion.
 Other responsibilities depend on the kind of proxy.

 RealSubject - the real object that the proxy represents

Applicability
 Proxies are useful wherever there is a need for a more sophisticated
reference to a object than a simple pointer or simple reference can
provide
 Use the Proxy Pattern to create a representative object that controls
access to another object, which may be remote, expensive to
create or in need of securing
 There are several use-case scenarios that are often repeatable in
practice

Applicability
 Remote Proxy
 The remote proxy provides a local representation of the object which is present
in the different address location

 Virtual Proxy
 delaying the creation and initialization of expensive objects until needed, where
the objects are created on demand

 Protection Proxy
 The protective proxy acts as an authorization layer to verify if the actual user has
access to appropriate content

 Smart Reference
 provides additional actions whenever a subject is referenced, such as counting
the number of references to an object

Applicability
 Firewall Proxy
 controls access to a set of network resources, protecting the subject from “bad”
clients

 Caching Proxy
 Provides temporary storage for results of operations that are expensive. It can
also allow multiple clients to share the results to reduce computation or network
latency

 Synchronization Proxy
 provides safe access to a subject from multiple threads

 Copy-On-Write Proxy
 controls the copying of an object by deferring the copying of an object until it is
required by a client. This is a variant of the Virtual Proxy

 Complexity Hiding Proxy

Example: Remote Proxy
 Solves the problem when the real subject is a remote object. A remote
object is object that exists outside of the current Java Virtual Machine
whether it be in another JVM process on the same machine or a far
machine accessible by network.
 The Remote Proxy pattern enables communication with minimal
modification to existing code
 The Remote Proxy acts as a local representative to the remote object
 The client call methods of the proxy
 The proxy forwards the calls to the remote object
 To the client, it appears as though it is communicating directly with the remote
object

public interface ISubject {
public String doHeavyTask(String arguments);
}
public class RealSubject implements ISubject{

@Override
public String doHeavyTask(String arguments) {
//do the heavy task..
//generate results
String results = new String("Results");
return results;
}
}

public class Proxy implements ISubject{
@Override
public String doHeavyTask(String arguments) {
//start of the stub routine
//pack arguments and generate the request..
//send the request and wait for the response
//unpack results from the response
String results = new String("Results");
//end of the stub routine
return results;
}
}

public class Skeleton {
/*
* */
public void receiveRequest(String request){
//unpack the request
//object?
RealSubject subject = new RealSubject();
//method? arguments?
String result = subject.doHeavyTask("arguments");
//pack response with the result
//send the response
}
}

Example: Virtual Proxy
 Solves the problems that arises while working directly with objects
that are expensive to create, initialize and maintain in concern with
time or memory consumption
 In this situations the Virtual Proxy:
 acts as a representative for an object that may be expensive to create
 often defers the creation of the object until it is needed
 also acts as a surrogate for the object before and while it is being
created. After that, the proxy delegates requests directly to the
RealSubject

class ImageProxy implements Icon {
ImageIcon imageIcon;
public int getIconWidth() {
if (imageIcon != null) {
return imageIcon.getIconWidth();
} else {
return 800;
}
}
public int getIconHeight() {
return imageIcon.getIconHeight();
} else {
return 600;
}
}
}

public void paintIcon(final Component c, Graphics g, int x, int y) {
imageIcon.paintIcon(c, g, x, y);
} else {
g.drawString("Loading CD cover, please wait...", x+300, y+190);
if (!retrieving) {
retrieving = true;
retrievalThread = new Thread(new Runnable() {
public void run() {
try {
imageIcon = new ImageIcon(imageURL, "CD Cover");
c.repaint();
} catch (Exception e) {}
}
});
retrievalThread.start();
}
}
}

 Refactoring the code:
URL url = new URL("http://images.amazon.com/images/some_image.jpg");
Icon icon = new ImageIcon(url);
Icon icon = new ImageProxy(url);
int iconHeight = icon.getIconHeight();
int iconWidth = icon.getIconWidth();
icon.paintIcon(c, g, x, y);

Related patterns
Many design patterns can have similar or exactly same structure but
they still differ from each other in their intent.
 Adapter design pattern
 Adapter provides a different interface to the object it adapts and
enables the client to use it to interact with it, while proxy provides the
same interface as the subject

 Decorator design pattern
 A decorator implementation can be the same as the proxy however a
decorator adds responsibilities to an object while a proxy controls access
to it

“

Thank you
for your attention

”

Sashe Klechkovski
December, 2013

Proxy design pattern

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Proxy design pattern

Similaire à Proxy design pattern (20)

Dernier

Dernier (20)

Proxy design pattern

Notes de l'éditeur