A rather vague pattern name, which might refer to any of the following:
In the GOF book, ProxyPattern is described with the following intent: "Provide a surrogate or placeholder for another object to control access to it."
This is a ProtectionProxy, or possibly CaretakerPattern. However, the term "proxy" is more commonly used to refer to RemoteProxy, or for handles / wrapper objects (see HandleBodyPattern).
Simply speaking, a Proxy object is one through which we control access to the actual object on which the functionality lies. Depending on the context in which the Proxy object is used, the Pattern is broadly divided into the following 3 types:
'Virtual Proxy:' Used for Lazy instantiation of objects or for Lazy processing. Suppose you need to support 'resource-hungry' objects that involve high amount of I/O or one those that involved a database transaction. One need not instantiate these objects until they are really required. The real object would get created only when the client actully requests for some of its functionality.
[This is LazyInstantiationPattern.]
'Remote Proxy:' Used to hide the communication mechanisms between remote objects. In RMI, for example, we have the stubs which act as Remote Proxies for the Skeleton.
[This is RemoteProxy.]
'Access Proxy:' Used to provide control over a sensitive master object. This proxy object could check for the client's access permission before allowing methods to be executed on the actual object.
[This is ProtectionProxy.]
There are also a proxy type called 'Smart Proxy'. This could provide additional functionality over that offered by the existing object.
[This is DecoratorPattern.]
eg. Suppose an existing class provides a set of non-threadsafe functions. Instead of modifying the existing class to be threadsafe, a smart proxy could be used to synchronize the method calls.
[This should probably be given another name; it is in CategoryConcurrencyPatterns. The Java collections API uses it.]
Could you list some example code for each kind of proxy? -- will.wang
KCS: The Proxy Class in Java and C# is the only way I know of to dynamically inherit an already instantiated object, and, in effect, create a sort of "Runtime Multiple Inheritance". More and more at work, I seeing how this can really help my multi-layered applications.
Proxies are Dangerous
SamGentile noted in his blog that "If the programming model for your distributed technology of choice includes the concept of a proxy, you're being forced into distributed object semantics".
http://home.earthlink.net/~huston2/dp/proxy.html
http://wiki.cs.uiuc.edu/patternStories/ProxyPattern
http://delphipatterns.blog.com/2011/02/22/proxy-2/
See also: CompositePattern, DecoratorPattern, DesignPatterns, LazyProxies