1

Unit 4Prototype

Summary prepared by Kirk Scott

2

Design Patterns in JavaChapter 18Prototype

Summary prepared by Kirk Scott

3

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

4

• 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

5

• 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

6

• 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?

7

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.

8

• 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

9

• The UML diagram shown on the next overhead illustrates one possible design approach

• 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

10

11

• 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

12

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

13

• 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

14

• public class OzPanel extends Jpanel implements Cloneable

• {• public OzPanel copy()• {• return (OzPanel) this.clone();• }• }

15

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

16

• 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

17

• 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

18

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?

19

• 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

20

• 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

21

22

• 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

23

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

24

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

25

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

26

• 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.”

27

• 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

28

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

29

• 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

30

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

31

• 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

32

• 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

33

• 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

34

• public class CupV21• {• private int seedCount;• private int whoseCup;• private CupV21 nextCup;

• public CupV21()• {• seedCount = 0;• whoseCup = 0;• nextCup = null;• }

• public CupV21 partiallyCopyPlayableCupToGiveCapturedCup()• {• CupV21 retCup = new CupV21();• retCup.whoseCup = this.whoseCup;• return retCup;• }

35

• public CupV21(int seedCountin, int whoseCupin)• {• seedCount = seedCountin;• whoseCup = whoseCupin;• nextCup = null;• }

• public CupV21(int seedCountin, int whoseCupin, CupV21 nextCupin)

• {• seedCount = seedCountin;• whoseCup = whoseCupin;• nextCup = nextCupin;• }

36

• public String toString()• {• return "CupV21[seedCount = " + seedCount• + ", whoseCup = " + whoseCup• + "]";• }

• public int getSeedCount()• {• return seedCount;• }

• public void addOneSeed()• {• seedCount++;• }

37

• public void addSomeSeeds(int seedsin)• {• seedCount += seedsin;• }

• public int getWhoseCup()• {• return whoseCup;• }

• public CupV21 getNextCup()• {• return nextCup;• }

38

• public void setNextCup(CupV21 nextCupin)• {• nextCup = nextCupin;• }

• public int removeSeeds()• {• int temp = seedCount;• seedCount = 0;• return temp;• }• }

39

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

40

• 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

41

• 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

42

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

43

• 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

44

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

45

46

Summary

• Prototyping means in some sense making new objects by copying existing objects

• It differs from cloning because only partial copies are created

• Some of the instance variable values of the new objects are the default values, while others are copied from the existing object.

• Prototyping is partial copying

47

The End