proxy

= = = PROXY =

The book’s description of the Factory Method Pattern is as follows:




 * Purpose**

Provide a surrogate or placeholder for another object to control access to it. An object representing another object.

The Proxy object offers the same interface as the target object. The Proxy object interacts with the target object on behalf of a client object and takes care of the specific details of communicating with the target object. As a result, client objects are no longer needed to deal with the special requirements for accessing the services of the target object.

A client can call the Proxy  object through its interface and the  Proxy  object in turn forwards those calls to the target object. Client objects need not even know that they are dealing with Proxy  for the original object. The Proxy  object hides the fact that a client object is dealing with an object that is either remote, unknown whether instantiated or not, or needs special authentication. In other words, a Proxy  object serves as a transparent bridge between the client and an inaccessible remote object or an object whose instantiation may have been deferred. Proxy objects are used in different scenarios leading to different types of proxies.

A Proxy can also be defined as a surrogate. In the real work a check 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".



= =

The user of the credit is authorized to withdrawal or purchase things with the credit card almost like it was cash. The bank can impose limitations such as the amount or restrict access with pin code. The user doesn’t have to know how the bank manages the money or where or what they place it in. He/she only has to know that there’s cash in there and that he can spend it

Below is a chart of some of the different proxy types:

= = *Most common types of Proxies

= Proxy vs. Decorator vs. Facade = Proxy - The client object cannot access the target object directly. - A Proxy object provides access control to the target object (in the case of the protection proxy). - A Proxy object does not add any additional functionality.

Decorator - The client object does have the ability to access the target object directly, if needed. - A Decorator object does not control access to the target object. - A Decorator adds additional functionality to an object.

Façade - A Façade object represents a subsystem of objects. - The client object does have the ability to access the subsystem objects directly, if needed. - A Façade object provides a simplified higher level interface to a subsystem of components.

Keep in mind the similarities between the Decorator and Proxy design patterns. Both patterns use a proxy that forwards method calls to another object, known as the //real subject.// The difference is that, with the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively constructed at runtime.

= Proxy versus Inheritance =

The Proxy pattern is one of the most important design patterns because it provides an alternative to extending functionality with inheritance. That alternative is //object composition,// where an object (proxy) forwards method calls to an enclosed object (real subject).

Object composition is preferable to inheritance because, with composition, enclosing objects can only manipulate their enclosed object through the enclosed object's interface, which results in loose coupling between objects. In contrast, with inheritance, classes are tightly coupled to their base class because the internals of a base class are //visible// to its extensions. Because of that visibility, inheritance is often referred to as //white-box reuse.// On the other hand, with composition, the internals of the enclosing object are //not//

= =

visible to the enclosed object (and vice-versa); therefore, composition is often referred to as //black-box reuse.// All things being equal, black-box reuse (composition) is preferable to white-box reuse (inheritance) because loose coupling results in more malleable and flexible systems.

= Proxy versus Decorator = Although you implement both patterns in an almost identical fashion, it's the //intent// of those patterns that differs. The Decorator pattern constructs objects at runtime by recursively enclosing an object within one or more decorators. The Proxy pattern acts as a stand-in for a real subject, which is set at compile time.

Conclusion
Proxies allow us to maintain true separation of code from a point of view of ownership and control of underlying classes that the proxy provides access to. All access that a proxy controls should be handled by the proxy as a separate domain; in other words, the process flow model performs its operations separately from the executing call.

Below is an example of the proxy pattern used in a banking environment.



code format="java" interface BankInfo { void depositCash; void spendCash; void takeCash; }

class Proxy implements BankInfo { private BankInfo implementation;

public Proxy { implementation = new Implementation; }

public void depositCash { implementation.depositCash; }

public void spendCash { implementation.spendCash; }

public void takeCash { implementation.takeCash; } }

class Implementation implements BankInfo { public void depositCash { System.out.println("Deposit cash"); } public void spendCash { System.out.println("Spend cash"); } public void takeCash { System.out.println("Take cash out"); } }

public class CreditCard { public static void main(String args[]) { Proxy p = new Proxy; p.depositCash; p.spendCash; p.takeCash; } } code



The credit card is allowed access to the Bank and is able to be used to deposit, spend and take out cash.



Composite ** PROXY ** Review


 * Chapters **