1. Design Patterns in Java Chapter 18 Prototype Summary prepared by Kirk Scott 1

2. The Introduction Before the Introduction I plan on cutting my losses on chapter 18 As far as I’m concerned, there is not much in chapter 18 to begin with Furthermore, some of what’s in it is an incomplete coverage of material that should be a review Other parts seem like marginally bad ideas And other parts simply seem marginally wrong 2

3. As a consequence, this set of overheads will be short Instead of trying to cover the chapter in detail, it will just cover the high and low points 3

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

5. The book now shows a UML diagram for an expanded abstract factory UI kit scenario There is the main UIKit class It has three subclasses for three additional UI environments 5

6. 6

7. The book uses this as the starting point for trying to come up with an example where you might use prototyping Instead of having three subclasses, 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 7

8. Challenge 18.1 A Prototype design will cut down on the number of classes that Oozinoz uses to maintain multiple GUI kits. Name two other pros or cons of this design approach. 8

9. Solution 18.1 Advantages of this design include the following. We can create new factories without creating a new class; we could even create a new GUI kit at runtime. 9

10. We can produce a new factory by copying one and making slight adjustments. For example, we can make the GUI kit for a beta release identical to the normal kit except for font differences. The Prototype approach lets a new factory’s buttons and other controls “inherit” values, such as colors, from a predecessor factory. 10

11. Disadvantages include the following: The Prototype approach lets us change values, such as colors and fonts, for each factory but does not allow us to produce new kits that have different behavior. The motivation for stopping the proliferation of UI kit classes is not clear; Why is this proliferation a problem? 11

12. We have to put the kit-initialization software somewhere, presumably on static methods on the proposed UIKit class. This approach doesn’t really cut down on the amount of code we have to manage. For the sake of completeness, the rest of the book’s answer is given on the next overhead, but I don’t propose to read it. 12

13. What’s the right answer? In a situation like this, it may help to experiment: Write code that follows both designs, and evaluate how the design looks in practice. There will be times, though, when team members fundamentally disagree about which direction to take. This is a good thing: It shows that you are surfacing issues and discussing design. If you never disagree, you are probably not hammering out the best design. (For those times when you do disagree, even after thoughtful discussion, you might use an architect, a lead designer, or a neutral third party to break ties.) 13

14. Comment mode on: The previous discussion was pretty much detached from reality The authors wanted to discuss design issues without really spelling out how prototyping would be accomplished Once you see some of their ideas on prototyping, you may be unsure whether the approach is a good idea anyway… 14

15. The next paragraph in the book reveals some serious weirdness on the part of the authors They talk about making objects by copying other objects You then find this sentence: “However, the Prototype approach in Java does not allow new objects to have methods different from those of their parent.” This is so poorly expressed it raises doubt about the authors’ grip on what they’re talking about 15

16. Prototyping with Clones This section of the chapter basically boils down to a (lame) review of cloning If you survived CS 202 and remember anything from it, there should no surprises here 16

17. Challenge 18.2 The Object class includes a clone() method that all objects inherit. If you’re not familiar with this method, look it up in online help or other documentation. Then write in your own words what this method does. 17

18. Solution 18.2 There is no reason to copy the book’s long- winded answer to this question The answer is that the clone() method inherited from the Object class makes shallow copies 18

19. Challenge 18.3 Suppose that the Machine class had two attributes: an integer ID and a Location, where Location is a separate class. Draw an object diagram that shows a Machine object, its Location object, and any other objects that result from invoking clone() on the Machine object. 19

20. Solution 18.3 There is no reason to copy the book’s long- winded answer to this question The UML diagram showing the result is given on the next overhead 20

21. 21

22. This is where the book goes completely off the rails Instead of just dealing with the various issues that come up with cloning, they decide to skirt these issues by writing copy() methods which are based on cloning It is tempting to think that this is somehow the result of the fact that the authors were originally C++ programmers, not Java programmers 22

23. The example they give is of a method that makes it possible to “copy” a panel, a GUI component The code is given on the next overhead 23

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

25. The book marks this code as “dangerous” This will be explained shortly Before getting into that I would observe that the code is both stupid and potentially wrong It’s stupid because it is just a sham attempt to make cloning public It’s also stupid because it still doesn’t deal with the issue that the inherited clone() method makes shallow copies 25

26. It is potentially wrong because it doesn’t include a try/catch block The copy() method doesn’t explicitly try to handle the throwing of a CloneNotSupported exception 26

27. As it turns out, the reason that the book claims the code is dangerous also seems stupid to me The authors point out the obvious fact that OzPanel, as a subclass of JPanel, will inherit attributes from it and all of its superclasses They illustrate that fact with the UML diagram on the following overhead 27

28. 28

29. They then point out that for GUI purposes, the most interesting attributes may come from the Component class These include things like the foreground, the background, and the font, for example They then propose a challenge which I also will find fault with 29

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

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

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

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

34. Comment mode on: Although the book says that this is prototyping in spirit, it doesn’t really make a copy of something When discussing cloning in CS 202, one of the valid (and possibly most desirable) options is just to forget about cloning and make objects from scratch 34

35. That’s essentially what this code does, but it’s not clear why it has to be dressed up as “prototyping” In addition, I find fault with the argument about what’s happening with the inherited attributes that aren’t explicitly set You can’t avoid inherited instance variables It’s just a question of what value they take on 35

36. If you truly wanted to do prototyping, then the “copy” should have the same values as the “original” In this case, instead of having the values of the original, the instance variables take on whatever values they are given by default construction This is not necessarily better It is just more limited It certainly means that the result is less of a prototype 36

37. Summary The book’s summary continues the pattern of the rest of the chapter Most of it is an unremarkable review of things already stated or claimed On the other hand, it also includes statements like those given on the next overhead As stated about an earlier passage, these ideas are so poorly expressed it raises doubt about the authors’ grip on what they’re talking about 37

38. “A major difference between calling a constructor and copying an object is that a copy typically includes some of the state of the original object. You can use this to your advantage, particularly when different “classes” of objects differ only in their attributes and not in their behaviors. In such a case, you can create new classes at runtime by crafting prototypical objects for a client to copy.” 38

39. The End 39