I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

Design Patterns Uncovered: The Proxy Pattern

  • submit to reddit

Today's pattern is the Proxy pattern, another simple but effective pattern that helps with controlling use and access of resources. 

Proxy in the Real World 

A Proxy can also be defined as a surrogate. In the real work a cheque or credit card is a proxy for what is in our bank account.  It can be used in place of cash, which is what is needed, and provides a means of accessing that cash when required. And that's exactly what the Proxy pattern does - controls and manage access to the object they are "protecting".

Design Patterns Refcard
For a great overview of the most popular design patterns, DZone's Design Patterns Refcard is the best place to start. 

The Proxy Pattern

The Proxy is known as a structural pattern, as it's used to form large object structures across many disparate objects. The definition of Proxy provided in the original Gang of Four book on Design Patterns states: 

Allows for object level access control by acting as a pass through entity or a placeholder object. 

So it's quite a simple concept - to save on the amount of memory used, you might use a Proxy. Similarly, if you want to control access to an object, the pattern becomes useful.

Let's take a look at the diagram definition before we go into more detail.

As usual, when dealing with design patterns we code to interfaces. In this case, the interface that the client knows about is the Subject. Both the Proxy and RealSubject objects implement the Subject interface, but the client may not be able to access the RealSubject without going through the Proxy. It's quite common that the Proxy would handle the creation of the RealSubject object, but it will at least have a reference to it so that it can pass messages along.

Let's take a look at this in action with a sequence diagram. 

 As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object. 

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

Would I Use This Pattern?

This pattern is recommended when either of the following scenarios occur in your application:

  • The object being represented is external to the system.
  • Objects need to be created on demand. 
  • Access control for the original object is required
  • Added functionality is required when an object is accessed.

Typically, you'll want to use a proxy when communication with a third party is an expensive operation, perhaps over a network. The proxy would allow you to hold your data until you are ready to commit, and can limit the amount of times that the communication is called.

The proxy is also useful if you want to decouple actual implementation code from the access to a particular library. Proxy is also useful for access to large files, or graphics. By using a proxy, you can delay loading the resource until you really need the data inside. Without the concept of proxies, an application could be slow, and appear non-responsive. 

So How Does It Work In Java?

Let's continue with the idea of using a proxy for loading images. First, we should create a common interface for the real and proxy implementations to use:

public interface Image
public void displayImage();

The RealImage implementation of this interface works as you'd expect:

public class RealImage implements Image

public RealImage(URL url)
//load up the image

public void displayImage()
//display the image

//a method that only the real image has
private void loadImage(URL url)
//do resource intensive operation to load image


Now the Proxy implementation can be written, which provides access to the RealImage class. Note that it's only when we call the displayImage() method that it actually uses the RealImage. Until then, we don't need the data.

public class ProxyImage implements Image
private URL url;

public ProxyImage(URL url)
this.url = url;

//this method delegates to the real image
public void displayImage()
RealImage real = new RealImage(url);


And it's really as simple as that. As far as the client is concerned, they will just deal with the interface. 

Watch Out for the Downsides

Usually this is the stage that I point out the disadvantages to the pattern. Proxy is quite simple, and pragmatic, and it's one pattern that I can't think of any downsides for. Perhaps you know of some? If so, please share them in the comments section.

Other Articles in This Series
The Observer Pattern
The Adapter Pattern
The Facade Pattern
The Factory Method Pattern
The Abstract Factory Pattern
The Singleton Pattern
The Strategy Pattern

Next Up

The Decorator pattern is a close relation to the Proxy pattern, so we'll take a look at that next week. 



Josh Marotti replied on Fri, 2010/03/12 - 6:41am

While you gave a simple example, a more complex example would be to use, say, an aspect as a proxy.  The downside here is 'magic' could be happening that an extender is unaware of (a 'black-box' problem).

Peter Veentjer replied on Fri, 2010/03/12 - 8:06am

There are 2 big problems with proxies, especially in enterprise environments.


1) You can't do self calls. A good example is a proxy that does transactionmanagement or security. So you need to make sure that instead of doing a self call, you forward the call to the proxy. This makes simple classes complex.

2) There are issues with identity; a good examlpe is a hibernate proxy which makes it impossible to do a reference comparison, even though you get the guarantee that there are not multiple object instances of the same entity in a session. 

So although a proxy is a nice design pattern in theory, it often sucks in practice.


Peter Veentjer

Multiverse Software Transactional Memory for Java


Neil Bartlett replied on Fri, 2010/03/12 - 7:09am

Since you asked, I can think of a couple of downsides -- though of course the pattern is still valuable.

First, a proxy can mask the lifecycle and state of a volatile resource from its client. A client may call the proxy not realising that the resource is currently unavailable... in this case the proxy has to either block until a resource is available again, or it must produce some kind of error. In Java terms it would have to be an unchecked exception, since the Proxy must comply with the interface of the original object. Also the client may not be aware that the resource it is calling now is not the same resource it called a second ago; if there is any state on the resource then the client may be confused that the state appears to have been forgotten.

Second, if a proxy is used to represent a remote resource in the local process, this can disguise the fact that remote communication is involved. As we know, remote invocation is completely different from local invocation, and our programs should not treat it as if it were the same. It is better if the proxy declares somehow that it is a proxy for a remote resource, rather than a local resource. Then clients would have be able to choose only local resources, or to modify their behaviour when using a remote resource.

James Sugrue replied on Fri, 2010/03/12 - 7:57am

Thanks for the downsides guys - keep them coming :)

Bogdan Marian replied on Mon, 2010/03/15 - 7:54am

By looking at the comments above, it looks like Proxy is a nasty design pattern.

But don't forget it is (was) used by Hibernate for implementing lazy loading...

Proxy can also be used for implementing AOP...

Allen Geer replied on Tue, 2010/03/23 - 8:57pm

I have found that using the proxy pattern, as implemented and defined in the Java specs, is a great solution for applications that have low load. But the computing time incurred with all the reflection calls nessecary to implement this pattern can slow an application down quite a bit. While elegant from a design prospective, the cost in terms of computational time can be somewhat limiting for high load situations.

Reza Ghafari replied on Tue, 2010/03/23 - 11:00pm

To me, the link between Proxy and RealSubject should be "optional" as we do not want to forward requests to the RealSubject in all the cases.

Mahesh Kulkarni replied on Thu, 2010/05/13 - 1:58am

Good Article... worth reading...

Sunny Gupta replied on Thu, 2013/08/15 - 1:14pm in response to: Neil Bartlett

 Hi Neil,

As you told that "the client may not be aware that the resource it is calling now is not the same resource it called a second ago", Did you refer the resource as actual resource or the proxy resource? Would you please elaborate

Also when you write "if there is any state on the resource then the client may be confused that the state appears to have been forgotten". Would you please explain this comment by some example.



Jeet Jain replied on Fri, 2013/08/16 - 12:26am in response to: Peter Veentjer

 Hi Peter,

I have few questions to you:

1) What is the meaning of self call

2) Why we can not do a reference comparison when both refers to proxy object

Manoj Kumar replied on Thu, 2013/09/26 - 11:18am

  Proxy Design Pattern in Java, lazy loading using Proxy Design Pattern

What is Proxy Design Pattern

1. Proxy design patten works on the principal of exposing an Java Instance through a proxy instead of actual object.

2. Client would never know anything about actual object and through Proxy only relevant behavior of actual object will be exposed to client.

3. Proxy Pattern can be used for applying security on actual Object. Service provider does not want actual class to be visible to any client Instead It would be shared as per Client contract agreement . Service provider may agree to share only a part of Service with it's client and for that It may expose a different contract in the form of interface in java .

4. This concept is very useful for lazily loading an instance . Data will be loaded only when it is actually required in an operation .

Learn more about proxy design pattern here  -- <a href="http://efectivejava.blogspot.in/2013/09/proxy-design-pattern-in-java-lazy.html?utm_source=BP_recent">Proxy Design Pattern</a>


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.