|
CS 635: Advanced Object-Oriented Design & Programming |
|
---|
Spring Semester, 1998
Proxy
To Lecture Notes Index
© 1998, All Rights Reserved, SDSU & Roger Whitney
San Diego State University -- This page last updated 21-Apr-98
Contents of Doc 24, Proxy
CS 635 Doc 24 Proxy
References | slide # 1 |
| |
Proxy | slide # 2 |
...Structure | slide # 2 |
...Dynamics | slide # 3 |
...Reasons for Object Proxies | slide # 4 |
References
Design Patterns: Elements of Reusable Object-Oriented Software, Gamma,
Helm, Johnson, Vlissides, Addison Wesley, 1995, pp 207-217
Pattern-Oriented Software: A System of Patterns, Buschman, Meunier,
Rohnert, Sommerlad, Stal, 1996, pp 263-275
Advanced C++: Programming Styles and Idioms, James Coplien, 1992, pp
58-72
CS 635 Lecture notes, 1998, Doc 22
http://www.eli.sdsu.edu/courses/spring98/cs635/notes/bridge/br
idge.html
Proxy
proxy n. pl prox-ies The agency for a person who acts as a
substitute for another person, authority to act for another
Structure
The Pattern
The proxy has the same interface as the original object
Use common interface (or abstract class) for both the proxy
and original object
Proxy contains a reference to original object, so proxy can
forward requests to the original object
Dynamics
Runtime Objects
Reasons for Object Proxies
Remote Proxy
- The actual object is on a remote machine (remote address
space)
- Hide real details of accessing the object
- Used in CORBA, Java RMI
public class HelloClient {
public static void main(String args[]) {
try {
String server = getHelloHostAddress( args);
Hello proxy = (Hello) Naming.lookup( server );
String message = proxy.sayHello();
System.out.println( message );
}
catch ( Exception error)
{ error.printStackTrace(); }
}
}
Reasons for Object Proxies Continued
Virtual Proxy
- Creates/accesses expensive objects on demand
- You may wish to delay creating an expensive object until it is
really accessed
- It may be too expensive to keep entire state of the object in
memory at one time
Protection Proxy
- Provides different objects different level of access to original
object
Cache Proxy (Server Proxy)
Multiple local clients can share results from expensive
operations: remote accesses or long computations
Firewall Proxy
- Protect local clients from outside world
Synchronization Proxy
Synchronize multiple accesses to real subject
public class Table {
public Object elementAt( int row, int column ){ blah }
public void setElementAt(Object element, int row, int column )
{ blah}
}
public class RowLockTable {
Table realTable;
Integer[] locks;
public RowLockTable( Table toLock) {
realTable = toLock;
locks = new String[ toLock.numberOfRows() ];
for (int row = 0; row< toLock.numberOfRows(); row++ )
locks[row] = new Integer(row);
}
public Object elementAt( int row, int column ) {
synchronized ( locks[row] ) {
return realTable.elementAt( row, column);
}
}
public void setElementAt(Object element, int row, int column ){
synchronized ( locks[row] ) {
return realTable.setElementAt(element, row, column);
}
}
}
Counting Proxy
- Delete original object when there are no references to it
- Prevent accidental deletion of real subject
- Collect usage statistics
- Sample use is making C++ pointer safe
C++ Counted String Pointer Classes
See Doc 22 slides 9-11
Proxy verses Other Patterns
Decorator
- Decorators add responsibility(ies) to an object
- Proxies controls access an object
Chain of Responsibility
- Chain can contain many objects
- In the chain different objects can perform various requests
- Proxy forwards (or not) requests to the original object
Facade
- A facade represents a system of objects
- A proxy represents a single object
- A facade simplifies the interact between client and the system
- A proxy controls the access to the single object
Observation
All the design patterns in the text are based on:
- programming to an interface
- using indirection (composition )
These two elements are used to construct communicating objects
and classes that solve a general design problem in a particular
context
The structures of different patterns may be similar but the problem
each pattern solves is different
Different pattern's problems may overlay at times
The goal is not to produce a disjoint taxonomy of structures but a
list of common problems and a general structure for solving them
© 1998, All Rights Reserved, SDSU & Roger Whitney
visitors since 21-Apr-98