1 / 63

Chapter 18 Prototype

Chapter 18 Prototype. Summary prepared by Kirk Scott. Design Patterns in Java Chapter 18 Prototype. Summary prepared by Kirk Scott. Ivory-billed Woodpecker From Wikipedia, the free encyclopedia Jump to: navigation , search Not to be confused with Ivory-billed Woodcreeper .

keiki
Télécharger la présentation

Chapter 18 Prototype

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 18Prototype Summary prepared by Kirk Scott

  2. Design Patterns in JavaChapter 18Prototype Summary prepared by Kirk Scott

  3. Ivory-billed Woodpecker • From Wikipedia, the free encyclopedia • Jump to: navigation, search • Not to be confused with Ivory-billed Woodcreeper.

  4. The Ivory-billed Woodpecker (Campephilusprincipalis) is one of the largest woodpeckers in the world, at roughly 20 inches in length and 30 inches in wingspan. It was native to the virgin forests of the southeastern United States (along with a separate subspecies native to Cuba). Due to habitat destruction, and to a lesser extent hunting, its numbers have dwindled to the point where it is uncertain whether any remain. Almost no forests today can maintain any Ivory-billed Woodpecker population.

  5. The name Campephilus means "lover of grubs" - an allusion to the diet of these birds, many of which feed on the larvae of wood-boring beetles. Contrary to long-held opinion, their closest relatives are not the large black Dryocopus woodpeckers: instead, they are related to the Chrysocolaptesflamebacks from Southeast Asia (Benz et al., 2006).

  6. Zygodactyly • Zygodactyly (from Greek ζυγον, a yoke) is an arrangement of digits in birds and chameleons, with two toes facing forward (digits 2 and 3) and two back (digits 1 and 4). This arrangement is most common in arboreal species, particularly those that climb tree trunks or clamber through foliage. Zygodactyly occurs in the parrots, woodpeckers (including flickers), cuckoos (including roadrunners), and some owls. Zygodactyl tracks have been found dating to 120-110 Ma (early Cretaceous), 50 million years before the first identified zygodactyl fossils.[2]

  7. Illustration of left foot, showing Zygodactyly typical of woodpeckers.

  8. The Introduction Before the Introduction • The goal of prototyping is to construct a new object based on an existing object • The bottom line is that if you remember the discussion of cloning from CSCE 202, you know the most important things there are to know about prototyping

  9. The range of options for copying/cloning includes: • Make a new object from scratch and initialize it to the values of an existing object • Make a shallow copy, assuming a shallow copy is acceptable • Make a deep copy • Either of the last two options may be done using a clone() method in Java

  10. The book suggests making “copy()” methods. • The new idea that comes with prototyping is making partial copy() methods • In other words, you make a copy of a given object, but some of the instance variables are initialized to default values, while others are initialized to the values in the object being copied

  11. Side Note on Terminology • If you talk about partial copies, it would be possible to slip into talking about a “partial clone” • I just wanted to suggest that “partial clone” is a contradiction in terms, and I would avoid that terminology

  12. Prototyping vs. Copying vs. Cloning • There is also a potential pitfall even when being careful to speak in terms of copy() methods rather than clone() methods • Copying may be a convenient way to bring useful instances of objects into existence, but the client needs to be aware of the distinction between copying and cloning • If the fact that something is a partial copy is important, it needs to be clear

  13. Book Definition of the Prototype Design Pattern • Book definition: • The intent of the Prototype pattern is to provide new objects by copying an example rather than by bringing forth new, uninitialized instances of a class.

  14. The book develops a concrete example that illustrates the use of prototyping • This is the first example we’ll see that exhibits these these characteristics: • It is based on Oozinoz • It is part of a larger, relatively complete, object-oriented, graphical code base • The example is based on showing one solution and then refactoring it by applying a pattern

  15. Rather than being given a toy example, we have to accept the premises of a complex system • We have to understand the shortcomings of a given design • We have to see how a subset of that system can be refactored with the design pattern

  16. The example involves alternative designs for a system that is supposed to support multiple graphical user interfaces • The graphical user interfaces are supported by an underlying user interface kit, a UIKit class, which contains methods which create elements of the UI

  17. This is an outline of the initial design: • There is a UIKit superclass • There are three subclasses, HandheldUI, WideScreenUI, and BetaUI • Each of the subclasses supports a separate look and feel for the application in different environments • The UML diagram shown on the next overhead illustrates this design approach

  18. An Alternative Design • The book uses this as the starting point for an example where you might use prototyping • Instead of having three subclasses to the UIKit class, this alternative is proposed: • The UIKit class should contain static methods which can be called in order to generate the UI objects needed for various different UI environments

  19. The Book’s Code for Implementing the Prototype Design Pattern • This is where the book gives initial example code that is supposed to implement the design pattern • Instead of dealing with prototyping by means of careful cloning, they implement prototyping by writing a copy() method which is based on cloning

  20. The example they give is of a method that makes it possible to “copy” a panel, a GUI component that might appear in a UIKit • The code is given on the next overhead

  21. public class OzPanel extends Jpanel implements Cloneable • { • public OzPanel copy() • { • return (OzPanel) this.clone(); • } • }

  22. Apparent Problems with the Book’s Example • The thing to understand is that the book is trying to go step-by-step • It starts with a scenario and proposes a solution • But the solution is not complete and correct • They’re trying to model the process of code development

  23. As part of their approach, the book kind of beats around the bush • I would like to lead by just pointing out some of the obvious flaws with what they’ve done so far • As given, the method doesn’t even accomplish the goal of doing a partial copy, the basic reason for creating copy() methods rather than using clone() methods

  24. At the same time, it seems to be both unwise and potentially wrong • It’s unwise because it is effectively just an attempt to make cloning public • If you’re going to clone, there is a way to make cloning public using the tools of Java

  25. It’s potentially wrong because it still doesn’t deal with the issue that the inherited clone() method makes shallow copies • We don’t know at this point whether deep or shallow copies are needed

  26. The copy() method also doesn’t include a try/catch block for the call to clone() • It doesn’t explicitly try to handle the throwing of a CloneNotSupported exception—which may result depending on how the clone() method was implemented

  27. Sometimes anomalies in the book can be explained by the fact that the authors started as C++ programmers • In this example, I don’t know enough about C++ to say whether that’s the case • If by chance you are a C++ programmer and you are comfortable with the way this code was written, my goal is to make you uncomfortable…

  28. The Book’s Critique of its own Example • The book actually does claim that their code is dangerous • This is allegedly due to its inheritance characteristics • The authors point out the obvious fact that OzPanel, as a subclass of JPanel, will inherit attributes from it and all of its superclasses

  29. Their point is that if you aren’t familiar with all of the superclasses, can you be satisfied with all of the default values that come from them? • The reality is, that as a dyed-in-the-wool object-oriented programmer, I am accustomed to accepting default initialization of inherited instance variables for a long time • Should I be worried?

  30. What’s the Real Point of the Book’s Example? • The book points out that for GUI purposes, the most important instance variables may actually be in a higher superclass, Component, not in JPanel • These attributes include things like the foreground, the background, and the font, for example • They illustrate that fact with the UML diagram on the following overhead

  31. What the book is driving at is that they’re trying to motivate the idea that you probably really want only a partial copy • In other words, they are conceding that a copy() method that is just a cloaked clone() method doesn’t really serve the purpose of prototyping • The book pursues this idea in the following challenge

  32. Challenge 18.4 • Write an OzPanel.copy2() method that copies a panel without relying on clone(). • Assume that the only attributes that are important to a copy are background, font, and foreground.

  33. Solution 18.4 • “A reasonable solution is as follows: • [Code is given on the next overhead.]

  34. public OzPanel copy2() • { • OzPanel result = new OzPanel(); • result.setBackground(this.getBackground()); • result.setForeground(this.getForeground()); • result.setFont(this.getFont()); • return result; • }

  35. Solution 18.4, continued: • Both the copy() method and the copy2() method relieve clients of OzPanel from invoking a constructor and thus support the Prototype idea. • However, the manual approach of copy2() may be much safer. • This approach relies on knowing which attributes are important to copy, but it avoids copying attributes that you may know nothing about.”

  36. Comment mode on: • To state the obvious, in this second example, the prototyping code does call a constructor rather than calling a clone() method • But the client code does not call the constructor directly • It is spared the trouble of extracting desired values to copy and then calling a constructor which accepts those values as paramenters

  37. Comment mode continued: • If prototyping is making a partial copy, then this example implements prototyping • It creates a new object from scratch, with default values for its instance variables • It then initializes some important instance variables to the values of the particular object that’s being prototyped

  38. Comment mode continued: • The book’s explanation seems a little garbled to me • It’s not that I’m worried about inherited instance variables in general, and their default initialization

  39. I am perfectly happy, as usual, to accept default initialization for large numbers of inherited instance variables that I know nothing about • It is precisely those that I do know something about that I choose to initialize to values I also know something about because they are the values in an object which I already have possession of

  40. I have a specific purpose in mind • If I’m thinking clearly, then it’s a simple matter to make sure I copy over the values that I really want • In this example, concretely, that makes sure there’s consistency between the different graphical user interfaces

  41. Another Example • You may recall the following from the development of the Wari examples in CSCE 202: • There was a version of the code where there was just one Cup class • That class had instance variables for an owner, a link to the next cup, and a count of the number of seeds • That cup class was suitable for the playable cups on the board

  42. By simply ignoring the link to the next cup, that cup class could also serve as a captured cup • An alternative design had the captured cup as a superclass, lacking a link, and the playable cup as a subclass, containing that additional instance variable

  43. It can’t be said that there is any particular advantage to using prototyping in this case, but the foregoing scenario can be adapted to illustrate prototyping. • You could use the design that only has the one kind of cup, and to create a captured cup for a given player, you could prototype one of that player’s playable cups.

  44. The captured cup would be a partial copy of the playable cup • You would want to copy the value indicating who the cup belonged to • You would want the seed count to be given the default initial value of 0, because that is how the captured cup should start—regardless of how many seeds might be in the playable cup that is being copied

  45. And you would want the link instance variable to take on the default value of null, because the captured cup is never linked to any other cup • The code for the CupV21 class is given on the overheads following the next one, with modifications

  46. The class has had a default constructor added to it • It has also had a prototyping method added to it • In order to make it easy to identify the changes, these have been put at the very beginning • The rest of the code is given for reference purposes

  47. public class CupV21 • { • private intseedCount; • private intwhoseCup; • private CupV21 nextCup; • public CupV21() • { • seedCount = 0; • whoseCup = 0; • nextCup = null; • } • public CupV21 partiallyCopyPlayableCupToGiveCapturedCup() • { • CupV21 retCup = new CupV21(); • retCup.whoseCup = this.whoseCup; • return retCup; • }

More Related