Technical Reference: Proxy : Design Pattern

- Proxy represents a standin object for the real object.

- This is required when the real object is complex to create, is not available, or for authentication purpose.

- For e.g. web service proxy, proxy authentication server etc.

- If creation of object is expensive, its creation can be postponed till the very need arises and till then, a simple object can represent it.

- A client obtains a reference to a Proxy, the client then handles the proxy in the same way it handles RealSubject and thus invoking the method doSomething(). At that point the proxy can do different things prior to invoking RealSubject’s doSomething() method. The client might create a RealSubject object at that point, perform initialization, check permissions of the client to invoke the method, and then invoke the method on the object. The client can also do additional tasks after invoking the doSomething() method, such as incrementing the number of references to the object.

Common Situations where the proxy pattern is applicable are:

Virtual Proxies: delaying the creation and initialization of expensive objects until needed, where the objects are created on demand (For example creating the RealSubject object only when the doSomething method is invoked).
Remote Proxies: providing a local representation for an object that is in a different address space. A common example is Java RMI stub objects. The stub object acts as a proxy where invoking methods on the stub would cause the stub to communicate and invoke methods on a remote object (called skeleton) found on a different machine.
Protection Proxies: where a proxy controls access to RealSubject methods, by giving access to some objects while denying access to others.
Smart References: providing a sophisticated access to certain objects such as tracking the number of references to an object and denying access if a certain number is reached, as well as loading an object from database into memory on demand.

Example: Virtual Proxy

public interface Access {

    public String getAccess();

}

public class RealAccess implements Access {

    String status = "";

    RealAccess(String arg) {

        status = arg;

    }

    public String getAccess() {

        return status;

    }

}

public class ProxyAccess implements Access {

    String status = "";

    RealAccess orgAccess = null;

    ProxyAccess(String arg) {

        status = arg;

    }

    public String getAccess() {

        if ( orgAccess == null ) {

            orgAccess = new RealAccess(status);

        }

        return orgAccess.getAccess();

    }

}

public class Client {
    public static void main( String [] args) {
        Access diskAccess = new ProxyAccess("33344");
        System.out.println("ACCESS CODE: " + diskAccess.getAccess());
    }
}

Q. Difference between Adapters and Proxy

A. The Adaptor pattern is used when you want to use a class that isn't useable in that particular context. The Proxy pattern is used when you have a class that can be used in the particular context, but for whatever reason it is too heavy or slow.

In the proxy pattern, the RealSubject and the Proxy both have the same interface, the Proxy is acting as a stand in for the RealSubject. In the Adaptor pattern, the Target and the Adaptee have different interfaces

and the Adaptor is converting requests from one interface to the other.

Q. Difference between Decorators and Proxy

A. Decorators never ever instantiate their surrogate objects. Decorators are always passed their surrogates in their constructors and perform actions on these surrogates.

Proxies on the other hand always obtain an instance of their surrogates (either via constructors or factories). Proxies therefore never really expose their underlying objects but decorators do.

Pattern	Description
Decorator	Wraps another object and provides aditional behaviour to it
Proxy	Wraps another object to control access to it
Adapter	Wraps another object and provides a different interface to it
Facade	Wraps a bunch of object to simlify there interface