The Proxy Design Pattern
Proxy means ‘in place of’, or ‘on behalf of’. These literal meanings of proxy directly explains Proxy Design Pattern.
Proxies are also called surrogates, placeholders, handles, and wrappers.
In a nutshell, a proxy “Controls and manage access to the object they are protecting”
When to use this pattern?
Proxy pattern is used when we need to create a wrapper to cover the main object’s complexity from the client.
Types of proxies
- Remote Proxy
- Virtual Proxy
- Protection Proxy
- Smart Proxy
Remote proxy:
“A remote proxy provides a local representative for an object in a different address space”.
They are responsible for representing the object located remotely. Talking to the real object might involve manipulation of data. All that logic is encapsulated in these proxies and the client application need not worry about them.
Virtual proxy:
“A virtual proxy basically creates expensive objects on demand”.
It is a placeholder for “expensive to create” objects. The real object is only created when a client first requests/accesses the object.
Protection proxy:
“A protection proxy controls access to the original object. Protection proxies are useful when objects should have different access rights”.
If an application does not have access to some resource then such proxies will talk to the objects in applications that have access to that resource and then get the result back.
Smart proxy:
“A smart reference is a replacement for a bare pointer that performs additional actions when an object is accessed”.
A smart proxy provides additional layer of security by interposing specific actions when the object is accessed. An example can be to check if the real object is locked before it is accessed to ensure that no other object can change it.
UML Diagram
Explanation:
- Both the Proxy and the RealSubject implement the Subject interface. This allows any client to treat the Proxy just like the RealSubject.
- The RealSubject is usually the object that does most of the real work; the Proxy controls access to it.
- The control may be needed if the Subject is running on a remote machine, if the Subjectis expensive to create in some way or if access to the subject needs to be protected in some way.
- The Proxy often instantiates or handle the creation of the RealSubject.
- The Proxy keeps a reference (pointer) to the Subject, so it can forward requests to the Subject when necessary.
- In some cases, the Proxy may be responsible for creating and destroying the RealSubject. Clients interact with the RealSubject through the Proxy.
Now let us try to understand this with some code. You can find the the code in my GitHub repository.
We shall consider an example of an Internet Proxy. Here, a client wishes to access internet but we shall add certain rules that will act as a firewall to enable restricted access to certain websites.
First, we shall define our Internet interface.
Now we shall define our actual internet class (Real Subject)
The Proxy class will implement the same Internet interface and add some additional rules that will mock the real internet.
Finally, we will write our client code that will try to access certain websites
The expected output of the code is:
Making connection to: www.google.com
Access Denied.
www.facebook.com is a restricted url
Benefits:
- Increased security.
- Increased performance of the application. (This pattern avoids duplication of objects which might be huge size and memory intensive)
- The remote proxy also ensures about security by installing the local code proxy (stub) in the client machine and then accessing the server with help of the remote code.
Drawbacks/Consequences:
This pattern introduces another layer of abstraction which sometimes may be an issue if the RealSubject code is accessed by the clients directly and some of them might access the Proxy classes.
This might cause disparate behaviour.
Additional:
There are few differences between the related patterns. Like
