Design Patterns & Refactoring Proxy Oliver Haase HTWG Konstanz - - PowerPoint PPT Presentation

design patterns refactoring
SMART_READER_LITE
LIVE PREVIEW

Design Patterns & Refactoring Proxy Oliver Haase HTWG Konstanz - - PowerPoint PPT Presentation

Design Patterns & Refactoring Proxy Oliver Haase HTWG Konstanz Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 1 / 14 Description I Classification : Object-based structural pattern Also known as : Surrogate Purpose :


slide-1
SLIDE 1

Design Patterns & Refactoring

Proxy Oliver Haase

HTWG Konstanz

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 1 / 14

slide-2
SLIDE 2

Description I

Classification: Object-based structural pattern Also known as: Surrogate Purpose: Control access to a subject through indirection, i.e. a placeholder object (proxy) that provides the same interface and that delegates operation calls to the actual subject. Applicability: Common reasons to hide a subject behind a proxy are:

local placeholder for remote communication; basic idea behind Remote Procecure Call (RPC), Remote Method Invocation (RMI) → Remote Proxy create expensive objects only on demand → Virtual Proxy Example: high resolution graphic in text document, virtual proxy might only know size (bounding box) and position. control access to original proxy → Protection Proxy access control can only mean to filter out interfaces that shall not be usable, or a full-fledged authentication and authorization mechanism.

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 2 / 14

slide-3
SLIDE 3

Description II

need for an “inteligent” reference that e.g. counts number of existing references to subject (needed for automatic garbage collection) → Smart Reference

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 3 / 14

slide-4
SLIDE 4

Structure

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 4 / 14

slide-5
SLIDE 5

Participants

Proxy:

has reference to real subject (might see real subject only as an instance

  • f type Subject)

implements type Subject controls access to real subject; might be responsible for creating real subject on demand further functionality depends on proxy kind

Subject: Common interface for RealSubject and Proxy → allows a proxy to substitute for a real subject. RealSubject: implements the real thing.

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 5 / 14

slide-6
SLIDE 6

Implementation

Example: A service interface that contains methods for usage, for administration, and methods to get a usage or administration proxy:

public i n t e r f a c e ServiceUsage { void use ( ) ; } public i n t e r f a c e S e r v i c e A d m i n i s t r a t i o n { void a d m i n i s t r a t e ( i n t s t a t e ) ; } public i n t e r f a c e S e r v i c e extends S e r v i c e A d m i n i s t r a t i o n , ServiceUsage { S e r v i c e A d m i n i s t r a t i o n getAdministrationProxy ( ) ; ServiceUsage getUsageProxy ( ) ; }

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 6 / 14

slide-7
SLIDE 7

Implementation

Simple Service implementation:

public c l a s s C o n c r e t e S e r v i c e implements S e r v i c e { private i n t s t a t e = 0; public void a d m i n i s t r a t e ( i n t s t a t e ) { t h i s . s t a t e = s t a t e ; } public void use () { System . out . p r i n t l n ( ” s t a t e : ” + s t a t e ) ; } public S e r v i c e A d m i n i s t r a t i o n getAdministrationProxy () { return new AdministrationProxy ( t h i s ) ; } public ServiceUsage getUsageProxy () { return new UsageProxy ( t h i s ) ; } }

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 7 / 14

slide-8
SLIDE 8

Implementation

Proxy classes:

p u b l i c c l a s s A d m i n i s t r a t i o n P r o x y implements S e r v i c e A d m i n i s t r a t i o n { p r i v a t e S e r v i c e A d m i n i s t r a t i o n d e l e g a t e ; p u b l i c A d m i n i s t r a t i o n P r o x y ( S e r v i c e A d m i n i s t r a t i o n d e l e g a t e ) { t h i s . d e l e g a t e = d e l e g a t e ; } p u b l i c void a d m i n i s t r a t e ( i n t v a l u e ) { d e l e g a t e . a d m i n i s t r a t e ( v a l u e ) ; } } p u b l i c c l a s s UsageProxy implements ServiceUsage { p r i v a t e ServiceUsage d e l e g a t e ; p u b l i c UsageProxy ( ServiceUsage d e l e g a t e ) { t h i s . d e l e g a t e = d e l e g a t e ; } p u b l i c void use () { d e l e g a t e . use ( ) ; } }

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 8 / 14

slide-9
SLIDE 9

Implementation

Sample application that creates a ConcreteService, then feeds an administration thread with an AdministrationProxy and a usage thread with a UsageProxy.

p u b l i c c l a s s A p p l i c a t i o n { p u b l i c s t a t i c void main ( S t r i n g [ ] args ) { C o n c r e t e S e r v i c e s e r v i c e = new C o n c r e t e S e r v i c e ( ) ; S e r v i c e A d m i n i s t r a t i o n sa = s e r v i c e . g e t A d m i n i s t r a t i o n P r o x y ( ) ; ServiceUsage su = s e r v i c e . getUsageProxy ( ) ; new Thread (new AdminThread ( sa ) ) . s t a r t ( ) ; new Thread (new UsageThread ( su ) ) . s t a r t ( ) ; }

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 9 / 14

slide-10
SLIDE 10

Implementation

p r i v a t e s t a t i c c l a s s AdminThread implements Runnable { p r i v a t e S e r v i c e A d m i n i s t r a t i o n sa ; p u b l i c AdminThread ( S e r v i c e A d m i n i s t r a t i o n sa ) { t h i s . sa = sa ; } p u b l i c void run () { i n t v a l u e = 0; while ( true ) { sa . a d m i n i s t r a t e(++v a l u e ) ; t r y { Thread . s l e e p ( 5 0 0 0 ) ; } catch ( Exception e ) {} } } }

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 10 / 14

slide-11
SLIDE 11

Implementation

p r i v a t e s t a t i c c l a s s UsageThread implements Runnable { p r i v a t e ServiceUsage su ; p u b l i c UsageThread ( ServiceUsage su ) { t h i s . su = su ; } p u b l i c void run () { while ( true ) { su . use ( ) ; t r y { Thread . s l e e p ( 2 0 0 0 ) ; } catch ( Exception e ) {} } } } }

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 11 / 14

slide-12
SLIDE 12

Implementation

Variant with dynamic proxies: Java allows to create dynamic proxies that implement a set of interfaces specified at run-time.

p u b l i c c l a s s C o n c r e t e S e r v i c e implements S e r v i c e { [ . . . ] p u b l i c S e r v i c e A d m i n i s t r a t i o n g e t A d m i n i s t r a t i o n P r o x y () { I n v o c a t i o n H a n d l e r h a n d l e r = new DelegationHandler ( t h i s ) ; return ( S e r v i c e A d m i n i s t r a t i o n ) Proxy . newProxyInstance ( S e r v i c e A d m i n i s t r a t i o n . c l a s s . g e t C l a s s L o a d e r ( ) , new C l a s s [ ] { S e r v i c e A d m i n i s t r a t i o n . c l a s s } , h a n d l e r ) ; } p u b l i c ServiceUsage getUsageProxy () { I n v o c a t i o n H a n d l e r h a n d l e r = new DelegationHandler ( t h i s ) ; return ( ServiceUsage ) Proxy . newProxyInstance ( ServiceUsage . c l a s s . g e t C l a s s L o a d e r ( ) , new C l a s s [ ] { ServiceUsage . c l a s s } , h a n d l e r ) ; }

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 12 / 14

slide-13
SLIDE 13

Implementation

Class DelegationHandler forwards all incoming calls to delegate object:

p u b l i c c l a s s DelegationHandler implements I n v o c a t i o n H a n d l e r { p r i v a t e Object d e l e g a t e ; p u b l i c DelegationHandler ( Object d e l e g a t e ) { t h i s . d e l e g a t e = d e l e g a t e ; } p u b l i c Object invoke ( Object arg0 , Method arg1 , Object [ ] arg2 ) throws Throwable { return arg1 . invoke ( delegate , arg2 ) ; } }

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 13 / 14

slide-14
SLIDE 14

Implementation

Java 5 and later uses dynamic proxies for Java RMI: When an RMI server object is exported, the runtime system (Java virtual machine) creates a dynamic proxy (RMI stub) that implements the respective remote interface, and forwards all methods calls to the remote server object. This obsoletes the necessity to create stub classes (rmic) beforehand.

Oliver Haase (HTWG Konstanz) Design Patterns & Refactoring 14 / 14