1 / 110

Chapter 11 Proxy

Chapter 11 Proxy. Summary prepared by Kirk Scott. Design Patterns in Java Chapter 11 Proxy. Summary prepared by Kirk Scott. The Downy Woodpecker ( Picoides pubescens ) is a species of woodpecker , the smallest in North America. The Introduction Before the Introduction.

denise
Télécharger la présentation

Chapter 11 Proxy

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. Chapter 11Proxy Summary prepared by Kirk Scott

  2. Design Patterns in JavaChapter 11Proxy Summary prepared by Kirk Scott

  3. The Downy Woodpecker (Picoidespubescens) is a species of woodpecker, the smallest in North America.

  4. The Introduction Before the Introduction • The chapter in the book is broken into four different parts • 1. An illustration of the design pattern for image loading • This example shows the accepted use of classes and relationships between them for implementing the proxy pattern • 2. A refactoring of the original design • The idea is that the same functional goal is achieved but by means which might be better

  5. 3. The book then considers the use of what it calls remote proxies • Proxies can definitely be useful in this environment • However, writing code that is distributed on different hardware platforms is beyond the scope of this course • Therefore, this section of the chapter will only be covered in passing

  6. 4. The last section of the chapter concerns dynamic proxies • This is also a useful application area for the design pattern • However, this is advanced in nature and it is not necessarily a frequently occurring application • Like the previous section, this will only be covered in passing

  7. Beginning of Book Material • Responsibility in a design means that every class implements the code to support itself • Recall how the builder pattern relaxed this • Some of the construction logic was offloaded • Proxy is another design pattern where, in order to achieve a particular goal, responsibility for a given class is apportioned into another class

  8. In simple terms, a proxy is a substitute that you give to a client when it requests a base object • There are 3 cases where this might be desirable: • 1. When the base object might take too long to load • 2. When the base object is on another computer • 3. When you would like to intercept method calls to a base object so that you can wrap the underlying call to that object with code of your own

  9. In those cases a software design might include a proxy class • A proxy object stands in for a base object • Calls are made on the proxy object • The proxy then forwards those calls to the base object • In other words, the proxy is responsible for providing a public interface for/receiving calls that are ultimately aimed at another, base class

  10. Book Definition of Pattern • Book definition: • The intent of the Proxy pattern is to control access to an object by providing a surrogate, or placeholder, for it.

  11. A Classic Example: Image Proxies • A proxy is a substitute or stand-in for a base object • As such, it is desirable for it to have a generic interface (set of public methods) that is nearly identical to the interface of the base object • The proxy works by receiving the calls and “judiciously”, selectively, or “with modifications” forwarding the requests to the underlying object

  12. The term “stand-in” has been used to describe a proxy • A proxy might also be understood as a wrapper, depending on how it’s implemented • Or it might be understood as a go-between • Because it stands between the client and the base object, it might forward some calls unchanged, while other calls may have code added or modified in some other way

  13. A classic use of proxies is to avoid the waiting time associated with loading images in applications • Suppose the application contains graphical elements which hold the images • A proxy for a graphical element could take the step of displaying a small, temporary image, while the real image is being loaded in the background

  14. In other words, a load() call is issued to the proxy • The proxy loads a temporary image and calls load() on the base object in the background • The real load() may be set to run in a separate thread

  15. The user sees the temporary image quickly and can proceed using the application • The loading time of the real image doesn’t affect the immediate response time needed to show the temporary image

  16. Something else to consider: • If the real image is important, can you really proceed to use the application without it? • If it’s not important, does it really matter what image you’re seeing on the screen? • Consider splash screens in Web pages • Basically, you’d like to show users one thing • In the meantime, showing them something else is better than showing them nothing at all

  17. An Illustration of How the Pattern Might Be Used • The next overhead illustrates the idea of a graphical placeholder in an application that is supposed to display a picture • Initially an application would present the “Absent” icon • After pressing the “Load” button, the “Loading…” icon would be displayed as a stand-in • In the background, the loading of the real image would be started, and eventually the real image would be displayed

  18. The Mechanics of the Example • From the standpoint of mechanics, the book proposes displaying .jpg images as icons that are inserted into labels • This is the basic syntax: • ImageIcon icon = new ImageIcon(“images/fest.jpg”); • JLabel label = new JLabel(icon);

  19. The idea now is to give the JLabel a proxy in place of the real icon object • Then • The application makes use of the label • The label makes use of the proxy • And the proxy calls the base image/icon object • The following sequence diagram illustrates the idea

  20. In the previous descriptions, reference was made to “loading an image in the background” • In this example this will mean having the proxy implement the Runnable interface so that the proxy can load the image in a separate thread

  21. If You’re Not Familiar with Threads, Don’t Worry • Depending on the organization of this course, threads may or may not be covered in it • If not, and you haven’t encountered threaded code in some other setting, don’t worry • Although part of this example, it is not central to the structure and intent of the design pattern

  22. Threads in the Example • If you have encountered threads before, you might consider this thought: • Multi-threading in a single processor environment may not lead to any real time savings • Threading means that execution will alternate between loading the image and whatever else the application may do

  23. The fundamental question is whether or not the real image is critical to the application • If the image is critical, it still wouldn’t be possible for the user to do anything of consequence until the thread loading the real image finishes running • In other words, the proxy is likely to be most useful when the image is not critical anyway

  24. The use of a proxy is apparently cosmetic • The reality is that large parts of graphical user interfaces are essentially cosmetic • When dealing with users, cosmetic approaches may be useful or desirable to keep people happy • Whether the image is critical or not, the proxy allows you to placate or amuse the user by showing something temporary

  25. One More Thought • The other thing to keep in mind about the example is that a proxy does not have to be for a graphical image • It can be for any object an application may need • At that point, “cosmetic” doesn’t do justice to the situation • Client code is receiving some temporary object in place of an object that is not yet available

  26. A UML Diagram for the Example • The book’s UML diagram showing the relationship between the example ImageIconand ImageIconProxy classes is given on the following overhead • This will be followed by a discussion of the structure of the pattern in general • Following that, the example will be covered in detail, with code

  27. Example UML

  28. The Critical Part of the Static Structure of the Pattern Example • There is a Java class, ImageIcon, which is the graphical item which is displayed in a JLabel • The proxy, ImageIconProxy, is a subclass of the ImageIcon class • The proxy class has an instance variable which is typed ImageIcon, the type of its superclass • The bare structure of the example can be summarized as shown in the simplified UML diagram on the following overhead

  29. The structure used to create a proxy is a class with a reference to an instance of its superclass • Most likely this is the first time you’ve seen this concept in practice and it may look a little strange

  30. Preview of Coming Attractions • Even though the book is interested in intent, it clearly, initially identifies this pattern by structure • As we will see, it ultimately finds the structure troublesome • It will eventually abandon this structure in favor of a simpler structure which it will call a “proxy in spirit”

  31. We will get another pattern in the future where a subclass has a reference to an instance of one of its superclasses, and that structure will be the accepted implementation of that pattern • It’s a little unfortunate that the first time it crops up, we will end up rejecting it, because the structure can be useful

  32. It’s another case where the book develops a pattern by giving an initial implementation with shortcomings and then trying to refactor to a better design

  33. Continuing the Discussion of the Example with the Initial Implementation Structure • The ImageIconProxy class shows 3 items typed to ImageIcon: • ABSENT, LOADING, and current • Obviously, ABSENT and LOADING are constants • current is the instance variable which is a reference to the icon which the proxy is currently displaying • Initially it is absent, then loading… • Finally, it will refer to the real image icon when that has been loaded and is being displayed

  34. Now consider the constructor and methods • The ImageIconProxy class takes the String path name of the real image to load as its construction parameter • And the ImageIconProxy class load method takes a reference to the frame of the application that is using it • The frame reference is used to refresh what is shown on the screen when the ImageIconProxy variable takes on a new value

  35. Finally, the ImageIconProxy class has a run() method because it’s threaded • Overall, the ImageIconProxy class inherits the public interface of its superclass, ImageIcon • The ImageIconProxy class overrides a few of the many methods in the ImageIcon class

  36. How It Works • Inline initialization of the value of current is done in the ImageIconProxy class code so that any instance of it starts as ABSENT • When an instance of the ImageIconProxy class is constructed, it takes in the String path name of an actual image to be loaded • First the ABSENT image is acquired • Then an instance variable for the path name is initialized with the input parameter

  37. Later, the client will call load() on the proxy • This causes the value of current to be switched to LOADING • load() then repaints the frame • After that, the load() method creates a new thread for loading the actual image and calls run() on it

  38. The run() method of the thread does the loading of the actual image, making use of the path name taken in at construction time • In the book, the code for the ImageIconProxy class is given in partial form, followed by a challenge to complete it • Instead of doing a challenge, the complete code is shown beginning on the following overhead.

  39. ImageIconProxy Code • 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 JFramecallbackFrame;

  40. public ImageIconProxy(String filename) • { • super(ABSENT.getImage()); • this.filename = filename; • } • public void load(JFramecallbackFrame) • { • this.callbackFrame = callbackFrame; • current = LOADING; • callbackFrame.repaint(); • new Thread(this).start(); • } • public void run() • { • current = new ImageIcon(ClassLoader.getSystemResource(filename)); • callbackFrame.pack(); • }

  41. public intgetIconHeight() • { • return current.getIconHeight(); • } • public intgetIconWidth() • { • return current.getIconWidth(); • } • public synchronized void paintIcon(Component c, Graphics g, int x, int y) • { • current.paintIcon(c, g, x, y); • } • }

  42. The Structure of a Proxy in Its Most Basic Form • The basic structure of the proxy pattern, as presented in the book, was mentioned earlier • It is repeated again here in some depth for reference purposes • The book is ready to critique the pattern and suggest an alternative • It’s helpful to see exactly what it’s talking about

  43. At the most basic level, the ImageIconProxy class has an instance variable which is a reference to an ImageIcon, the current image • The situation can be diagrammed as shown on the following overhead

  44. The ImageIconProxy class is a subclass of the ImageIcon class • It also implements the Runnable interface • A more complete diagram, including those elements, is shown on the following overhead • Note that implementing the Runnable interface is incidental, but not necessarily fundamental to the pattern

More Related