Design Patterns in Java: Proxy
- A Classic Example: Image Proxies
- Image Proxies Reconsidered
- Remote Proxies
- Dynamic Proxies
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
An ordinary object does its own work in support of the public interface that it advertises. It can happen, though, that a legitimate object cannot live up to this ordinary responsibility. This may occur when an object takes a long time to load, when the object is running on another computer, or when you need to intercept messages to the object. In these cases, a proxy object can take the responsibility that a client expects and forward requests appropriately to an underlying target object.
The intent of the Proxy pattern is to control access to an object by providing a surrogate, or placeholder, for it.
A Classic Example: Image Proxies
A proxy object usually has an interface that is nearly identical to the interface of the object it is a proxy, or substitute, for. The proxy does its work by judiciously forwarding requests to the underlying object that the proxy controls access to. A classic example of the Proxy pattern relates to avoiding the expense of loading large images into memory. Suppose that images in an application belong in pages or panels that do not initially display. To avoid loading all the images before they are needed, you might let proxies for the images act as placeholders that load the required images on demand. This section provides an example of an image proxy. But note that designs that use Proxy are sometimes brittle, because they rely on forwarding method calls to underlying objects. This forwarding may create a fragile, high-maintenance design.
Suppose that an Oozinoz engineer is working on an image proxy that will, for performance reasons, show a small, temporary image while a larger image is loading. The engineer has a prototype working (Figure 11.1). The code for this application is in the ShowProxy class in the app.proxy package. The underlying code that supports the application is in the com.oozinoz.imaging package.
)
Figure 11.1 Three screen shots show a mini-application before, during, and after loading a large image. (Image is in the public domain. Library of Congress, Prints and Photographs Division, Gottscho-Schleisner Collection [LC-G605-CT-00488].)
The user interface displays one of three images: one that indicates that loading has not begun, one that indicates that the real image is loading, or the real image. When the application starts, it shows Absent, a JPEG image that you have built in an image-processing tool. When the user clicks Load, the image changes almost instantly to a prebuilt _Loading... image. After a few moments, the desired image appears.
An easy way to display an image saved in, say, a JPEG file is to use an ImageIcon object as an argument to a “label” that will show the image:
ImageIcon icon = new ImageIcon("images/fest.jpg"); JLabel label = new JLabel(icon);
In the application that you are building, you want to pass into JLabel a proxy that will forward painting requests to (1) an “absent” image, (2) a “loading” image, or (3) the desired image. The message flow might look like the sequence diagram in Figure 11.2.
)
Figure 11.2 An ImageIconProxy object forwards paint() requests to the current ImageIcon object.
When the user clicks Load, your code will cause the ImageIconProxy object to change its current image to the Loading... image. The proxy will also begin loading the desired image. When the desired image is completely loaded, the ImageIconProxy object will change its current image to be the desired image.
To set up a proxy, you can create a subclass of ImageIcon, as Figure 11.3 shows. The code for ImageIconProxy defines two static variables that contain the Absent and Loading... images:
static final ImageIcon ABSENT = new ImageIcon(
ClassLoader.getSystemResource("images/absent.jpg"));
static final ImageIcon LOADING = new ImageIcon(
ClassLoader.getSystemResource("images/loading.jpg"));
)
Figure 11.3 An ImageIconProxy object can stand in for an ImageIcon object because an ImageIconProxy object is an ImageIcon object.
The constructor for ImageIconProxy accepts the name of an image file to eventually load. When an ImageIconProxy object’s load() method is called, it sets the image to LOADING and starts a separate thread to load the image. Using a separate thread keeps the application from waiting while the image loads. The load() method accepts a JFrame object that the run() method calls back once the desired image is loaded. The almost-complete code for ImageIconProxy.java is:
package com.oozinoz.imaging;
import java.awt.*;
import javax.swing.*;
public class ImageIconProxy
extends ImageIcon implements Runnable {
static final ImageIcon ABSENT = new ImageIcon(
ClassLoader.getSystemResource("images/absent.jpg"));
static final ImageIcon LOADING = new ImageIcon(
ClassLoader.getSystemResource("images/loading.jpg"));
ImageIcon current = ABSENT;
protected String filename;
protected JFrame callbackFrame;
public ImageIconProxy(String filename) {
super(ABSENT.getImage());
this.filename = filename;
}
public void load(JFrame callbackFrame) {
this.callbackFrame = callbackFrame;
current = LOADING;
callbackFrame.repaint();
new Thread(this).start();
}
public void run() {
current = new ImageIcon(
ClassLoader.getSystemResource(filename));
callbackFrame.pack();
}
public int getIconHeight() { /* Challenge! */ }
public int getIconWidth() { /* Challenge! */ }
public synchronized void paintIcon(
Component c, Graphics g, int x, int y) {
// Challenge!
}
}
Challenge 11.1
An ImageIconProxy object accepts three image display calls that it must pass on to the current image. Write the code for getIconHeight(), _getIconWidth(), and paintIcon() for the ImageIconProxy class.
A solution appears on page 376.
Suppose that you get the code working for this small demonstration application. Before you build the real application, which has more than just a Load button, you hold a design review, and the fragility of your design comes to light.
Challenge 11.2
The ImageIconProxy class is not a well-designed, reusable component. Point out two problems with the design.
A solution appears on page 376.
As you review someone’s design, you must concurrently form an understanding of the design and your opinion of the design. When you encounter a developer who feels that he or she is using a specific design pattern, you may disagree about whether the pattern is present. In this example, the Proxy pattern is evident but does not demonstrate that the design is good; in fact, much better designs exist. When the Proxy pattern appears in a design, its presence should be justified, because the use of forwarding can create problems that other designs may avoid. As you read the next section, you should form an opinion about whether Proxy is a desirable choice.