Applied Design Patterns with Java

Structural :: Proxy (207) {C ch 15}

Implementation

Here are implementation issues to consider when using the Proxy pattern:

1. Overloading the member access operator in C++. Java does not currently support operator overloading.
2. Using doesNotUnderstand in Smalltalk. Java does not support this feature.
3. Proxy doesn't always have to know the type of real subject. If a Proxy class can deal with its subject solely through an abstract interface, then there's no need to make a Proxy class for each RealSubject class; the Proxy can deal with all RealSubject classes uniformly. But if Proxies are going to instantiate RealSubjects (such as in a virtual proxy), then they have to know the concrete class.
4. How to refer to the subject before it's instantiated. Some Proxies have to refer to their subject whether it's on disk or in memory. That means they must use some form of address space-independent object identifiers. A file name was used for this purpose in the Motivation.

Related Patterns

Adapter (139) provides a different interface to the object it adapts. In contrast, a Proxy provides the same interface as its subject. However, a Proxy used for access protection might refuse to perform an operation that the subject will perform, so its interface may be effectively a subset of the subject's.

Decorator (175): Although Decorators can have similar implementations as Proxies, Decorators have a different purpose. A Decorator adds one or more responsibilities to an object, whereas a Proxy controls access to an object.

Proxies vary in the degree to which they are implemented like a Decorator. A protection proxy might be implemented exactly like a Decorator. A remote proxy will not contain a direct reference to its real subject but only an indirect reference, such as "host ID and local address on host." A virtual proxy will start off with an indirect reference such as a file name but will eventually obtain and use a direct reference.

Catalog Structural Prev Next