Unit 4 Prototype

1. Unit 4Prototype 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.

6. 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).

7. 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]

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

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

10. You have a range of options: • 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

11. As you will see, the book suggests making “copy()” methods. • The idea would be that you make a “partial clone” or partial copy • 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

12. There is a trade-off when taking this approach • Copying may be a convenient way to bring useful instances of objects into existence, but the client needs to understand what copying is • Does the user know what a copy() method does when it’s called and how it differs from a real clone() method?

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 tries to develop a concrete example that illustrates the use of prototyping • 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

15. The UML diagram shown on the next overhead illustrates one possible design approach • There is a UIKitsuperclass • There are three subclasses, HandheldUI, WideScreenUI, and BetaUI • Each of the subclasses supports a separate look and feel for the application in different environments

17. 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

18. 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 just dealing with prototyping by means of careful cloning, they implement prototyping by writing a copy() method which is based on cloning

19. In any case, 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

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

21. Problems with the Book’s Example • I am including this example because the book leads with it and because I find it so flawed that I think its flaws need to be mentioned • 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 • At the same time, it seems to be both unwise and potentially wrong

22. 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 • It’s potentially wrong because it still doesn’t deal with the issue that the inherited clone() method makes shallow copies

23. The copy() method also doesn’t include a try/catch block • It doesn’t explicitly try to handle the throwing of a CloneNotSupported exception—which may result depending on how the clone() method was implemented • Sometimes anomalies in the book can be explained by the fact that the authors started as C++ programmers • It isn’t clear whether that is the case with this example

24. The Book’s Critique of its own Example • The book actually does claim that the 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 • 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?

25. When you make a copy, all inherited instance variables will be initialized to agree with the copy • The book points out that for GUI purposes, the most important instance variables may actually be in a higher superclass, Component, not in JPanel

26. 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

28. What the book is driving at is 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

29. 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.

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

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

32. 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. • [In this second example, the prototyping code does call a constructor rather than calling a clone() method.] • 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.”

33. Comment mode on: • 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

34. Another Example • You may recall the following from the development of the Wari examples in CS 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

35. 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

36. 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.

37. 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

38. 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

39. 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

40. 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; • }

41. public CupV21(intseedCountin, intwhoseCupin) • { • seedCount = seedCountin; • whoseCup = whoseCupin; • nextCup = null; • } • public CupV21(intseedCountin, intwhoseCupin, CupV21 nextCupin) • { • seedCount = seedCountin; • whoseCup = whoseCupin; • nextCup = nextCupin; • }

42. public String toString() • { • return "CupV21[seedCount = " + seedCount • + ", whoseCup = " + whoseCup • + "]"; • } • public intgetSeedCount() • { • return seedCount; • } • public void addOneSeed() • { • seedCount++; • }

43. public void addSomeSeeds(intseedsin) • { • seedCount += seedsin; • } • public intgetWhoseCup() • { • return whoseCup; • } • public CupV21 getNextCup() • { • return nextCup; • }

44. public void setNextCup(CupV21 nextCupin) • { • nextCup = nextCupin; • } • public intremoveSeeds() • { • int temp = seedCount; • seedCount = 0; • return temp; • } • }

45. Comments on the Example • Notice that in this example cloning is not used • The prototyping method starts by calling the default constructor to make a brand new object with default values • It then takes the one instance variable value of the implicit parameter that is of interest and uses it to set the value in the object to be returned

46. When considering the code, you might wonder about this: • What would happen if you called the prototyping method on a captured cup rather than a playable cup? • Syntactically it would work, although practically there should be no reason to do this

47. The moral of the story is that in a design that includes this pattern, as always, writers of client code have to know what they’re doing • The result of a call to prototype is an object of the right type to call the prototyping method on again, but it makes little sense to do so • You would just go in circles, deriving useless new objects

48. UML for the Pattern • The prototype pattern is so simple that I have devised no particular UML diagram that illustrates it • You would might include it in a UML diagram of a design, or recognize it in a UML diagram of a design, by means of a method given in the box representing a class

49. The method may have a name, like copy(), or prototype(), that indicates that it implements the pattern • The diagram may also included a box with a dog-eared corner that shows the code or contains a comment that makes it clear that the method in question implements prototyping

50. Lasater’s UML diagram is given on the next overhead. • Using that author’s terminology, the pattern is recognizable by the subclass, the operation() method to prototype, and the use of the clone() method in the prototype classes.