Friday, November 23, 2012

Proxy Design Pattern

Although they are lots of books and articles about Design Patterns, yet I like to share my point of view about common design patterns with you, and would be happy to have your thoughts or questions on comments. This post introduces GoF Proxy design pattern.

Provide a surrogate or placeholder for another object to control access to it. (dofactory)

  • Proxy  maintains a reference that lets the proxy access the real subject. Proxy may refer to a Subject if the RealSubject and Subject interfaces are the same. It provides an interface identical to Subject's so that a proxy can be substituted for for the real subject and controls access to the real subject and may be responsible for creating and deleting it. Other responsibilites depend on the kind of proxy:
    • Remote proxies are responsible for encoding a request and its arguments and for sending the encoded request to the real subject in a different address space.
    • Virtual proxies may cache additional information about the real subject so that they can postpone accessing it. For example, the ImageProxy from the Motivation caches the real images's extent.
    • Protection proxies check that the caller has the access permissions required to perform a request.
  • Subject  defines the common interface for RealSubject and Proxy so that a Proxy can be used anywhere a RealSubject is expected.
  • RealSubject defines the real object that the proxy represents.


There are four common situations in which the Proxy pattern is applicable.
  • A virtual proxy is a placeholder for “expensive to create” objects. The real object is only created when a client first requests/accesses the object.
  • A remote proxy provides a local representative for an object that resides in a different address space. This is what the “stub” code in RPC and CORBA provides.
  • A protective proxy controls access to a sensitive master object. The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request.
  • A smart proxy interposes additional actions when an object is accessed. Typical uses include: 
    • Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
    • Loading a persistent object into memory when it’s first referenced,
    • Checking that the real object is locked before it is accessed to ensure that no other object can change it.
  • A Cache Proxy improves the performance of the underlying object's members when they perform long-running tasks that return seldom-changing results. For example, the underlying object may provide a method that calculates prime numbers. When the first call to the proxy's matching method is made, the call is passed to the real object. The results from the call are stored within the proxy object and returned to the client. For subsequent calls, the cached information in the proxy can be returned without recalculating the prime numbers.
  • DynamicProxy generates proxies for objects that can be used to transparently add or alter behavior to them, provide pre/post processing and many other things. The dynamic proxy provides one interceptor handler for all methods, and you can have many interceptors on one class.
    • Castle DynamicProxy is a library for generating lightweight .NET proxies on the fly at runtime. Proxy objects allow calls to members of an object to be intercepted without modifying the code of the class.
  • TransparentProxy is a run-time generated proxy like dynamic proxy 
    • WCF dynamic proxy is named TransparentProxy

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. In java RMI an object on one machine (executing in one JVM) called a client can invoke methods on an object in another machine (another JVM) the second object is called a remote object. The proxy (also called a stub) resides on the client machine and the client invokes the proxy in as if it is invoking the object itself (remember that the proxy implements the same interface that RealSubject implements). The proxy itself will handle communication to the remote object, invoke the method on that remote object, and would return the result if any to the client. The proxy in this case is a Remote proxy.

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.

  • Provide a surrogate or placeholder for another object to control access to it.
  • Use an extra level of indirection to support distributed, controlled, or intelligent access.
  • Add a wrapper and delegation to protect the real component from undue complexity.

  • Less efficiency due to indirection.

Sample Code
Virtual proxy example

Remote proxy example

Protective proxy example

Smart proxy example


Castle DynamicProxy example

Related Patterns
  • Adapter provides a different interface to its subject. Proxy provides the same interface. Decorator provides an enhanced interface.
  • Decorator and Proxy have different purposes but similar structures. Both describe how to provide a level of indirection to another object, and the implementations keep a reference to the object to which they forward requests.


Further readings

No comments :

Post a Comment