1 / 13

The Proxy Design Pattern (1) A structural design pattern Intent

The Proxy Design Pattern (1) A structural design pattern Intent Provide a surrogate or placeholder for another object to control access to it. The Proxy Design Pattern (2) Problem Situation I: Wish to control access to an object because: Housekeeping activities are required

anais
Télécharger la présentation

The Proxy Design Pattern (1) A structural design pattern Intent

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Proxy Design Pattern (1) • A structural design pattern • Intent • Provide a surrogate or placeholder for another object to control access to it

  2. The Proxy Design Pattern (2) • Problem • Situation I: Wish to control access to an object because: • Housekeeping activities are required • Protection levels exist • Objects sit in different address spaces • Actual object too expensive to build immediately • Situation II: Wish to provide transparent management of services • The client “thinks” it is using the actual service when rather it is using a proxy for the actual service

  3. The Proxy Design Pattern (3) • Non-software example (1) • Toll-free numbers • Client dials the “800” area code just like they would for a real area code • Proxy records billing information and connects to actual area code

  4. The Proxy Design Pattern (4) • Non-software example (2) • Checks • Check is a proxy for the actual funds in the bank

  5. The Proxy Design Pattern (5) • Abstract Description • Object Proxy Pattern Notice the “is-a” and “has-a” relations again.

  6. The Proxy Design Pattern (6) • Abstract Description • Sequence Diagram (typical proxy application)

  7. The Proxy Design Pattern (7) • Consequences • Isolates RealSubject from client • Forces controllable indirection • Costs indirection • True for all delegation models • May require duplicate information in Proxy and RealSubject • Must support same “properties” • These must be supported even before instantiation of RealSubject

  8. The Proxy Design Pattern (8) • Consequences • Creates second class dependent on Subject interface • Unavoidable in this pattern • Client may need to be aware of Proxy • For example, extra failure modes • Example: java.rmi.MarshalException in RMI

  9. The Proxy Design Pattern (9) • Implementation Issues • Three basic types of proxies • 1. Remote Proxy • Proxy used to “hide” the location of RealSubject • Example: RMI implementation • 2. Virtual Proxy • Performs optimizations • Example: Image rendering in HTML

  10. The Proxy Design Pattern (10) • Implementation Issues • Three basic types of proxies • 3. Housekeeping Proxy • Performs additional maintenance duties • Example: Cache Proxy • Example: Protection Proxy

  11. The Proxy Design Pattern (11) • Implementation Issues • Proxy can be written independent of RealSubject • Use Subject interface in definition of Proxy • Difficult (or impossible) if Proxy stores redundant information

  12. The Proxy Design Pattern (12) • Common Variations • Firewall Proxy (a protection proxy) • Protects targets from bad clients (or vice versa) • Synchronization Proxy (a housekeeping proxy) • Provides multiple accesses to a target object • Smart Reference Proxy (a housekeeping proxy) • Provides additional actions whenever a target object is referenced • Copy-on-Write Proxy (a virtual proxy) • Defers cloning an object until required

  13. The Proxy Design Pattern (13) • Java API Usage • java.rmi library • “Remote Method Invocation” • Allows objects in separate virtual machines to be used as if local (language specific) • Uses “stub and skeleton” to handle communication

More Related