Download CS 304, Example Questions 3 Most of the questions in this

1
CS 304, Example Questions 3
Most of the questions in this document are designed as short answer questions, whether
the answer is code or not. Some of the questions also include enough given code that you could
create an answer that consisted of one or more classes that you could compile and test. These
questions are identified, in case you would like to do so. The given include is simply included in
this text document. It would be a simple matter to copy and paste it into TextPad, for example,
and save and compile it as Java code.
Following is a summary of conventions that should be used when considering questions
which either include a UML diagram as part of the set-up, or request that you answer with a
UML diagram.
1. Objects, classes, and interfaces are represented by boxes.
2. Classes can list instance variables, constructors, and methods.
3. Abstract classes, methods, etc. are formally given in italics. Since this isn't possible in
handwriting, abstract items should have the label "abstract" in front of them.
4. Interfaces are labeled with the word "interface" in front of them.
5. A solid line with a closed (white) arrowhead represents inheritance.
6. A dashed line with a closed (white) arrowhead represents implementing an interface.
7. A solid line with a diamond (white) represents composition.
8. A solid line with an open (feathered) arrowhead can mean "makes use of". It can also
specifically symbolize that one class has a reference to another as an instance variable.
9. A dashed line with an open arrowhead symbolizes a dependency (or "makes use of") between
classes where the used object is not an instance variable of the object that uses it. The object that
uses the other object may obtain the reference as a parameter, construct it, or acquire it in some
other way; the point is that it may be contained in a temporary or some other reference, but it's
not stored as an instance variable value.
I. Unit 25, Ch. 5, Composite
1. Let the following descriptively named classes be given: GamePiece, GameComponent, and
GameComposite. Give a UML diagram that shows them in a relationship that reflects the
Composite design pattern.
2
Assume that the GameComponent class contains this descriptive abstract method
declaration:
public abstract int getPieceCount();
2. Provide an implementation of the getPieceCount() method suitable for the GamePiece class.
For the purposes of the answer to the following question, assume that you only construct
tree-like structures and that your code does not have to deal with un-tree-like structures. Assume
that the GameComposite class maintains an ArrayList named componentList which contains the
components belonging to a composite instance. The list is declared and constructed like this:
private ArrayList<GameComponent> componentList = new
ArrayList<GameComponent>();
3. Complete the implementation of the getPieceCount() method for the GameComposite class.
public int getPieceCount()
{
int pieceCount = 0;
for(GameComponent aGameComponent:
{
componentList)
____________________________________________________________________;
}
return___________________________________________;
}
II. Unit 26, Ch. 12, Chain of Responsibility
The UML diagram shown below gives a concrete example of the Composite design
pattern. A Seed object is a leaf, a Cup object is a composite, and a GamePiece is a component.
Assume that only tree-like structures will be created using this composite. This means that there
will be a root to such a structure. The diagram shows a subclass of the Cup class, GameRoot,
which will be the type of the root node when a tree structure is created.
3
GamePiece
Seed
Cup
GameRoot
The scenario for the following questions is this: When a tree structure is created, each
object, or node, except for the root has a parent, and is given a reference to it. Also, there will be
another class in the design, Owner. Every game piece ultimately will have an owner and a
getOwner() method can be called on a game piece. If the game piece has an owner directly
recorded for it, the getOwner() method returns this. If the game piece doesn't have a value
directly recorded for it, then its owner is its parent's owner—recursively up through the hierarchy
of the tree. In other words, a call to getOwner() may trigger a call to getOwner on the parent.
Do not be confused. This does not mean that a call to get owner on a Seed, for example,
will trigger a super call to getOwner() on a GamePiece. The hierarchy under consideration is not
the inheritance hierarchy shown in the UML diagram of the design pattern. It is the hierarchy of
a tree formed by nodes consisting of instances of the concrete classes in the design pattern.
4. Based on the foregoing verbal description, using instance variable names myOwner and
myParent, give the declaration lines of code that would be needed in the GamePiece class to
support ownership and parenthood. Also write the set methods for these instance variables.
4
5. Logically, a parent would be a composite object, a Cup. However, due to Java syntax and the
structure of the design pattern, it should be given the type of the component, GamePiece. If you
made a mistake in your answer to the previous question, go back and change it. In the space
below, explain what the syntactical/structural reason is that requires the instance variable
capturing parenthood, declared in the GamePiece class and inherited by its subclasses, to be
typed GamePiece and not Cup.
It is important to make sure that a structure (for example, a tree) based on the Composite
design pattern will be linked up correctly to support the Chain of Responsibility design pattern.
This can be accomplished by requiring that the constructors for Seeds and Cups have a parameter
so that a reference capturing parenthood can be passed in to the object being created. Enforcing
a non-null constraint on this parenthood construction parameter can be accomplished by having
the constructor throw an exception if the parameter passed in is null. Seeds and Cups don't have
to have direct ownership. However, the root does. The same technique of exception throwing
can be used to enforce construction of a root with an owner.
6. The majority of the constructor for the Cup class is given below. Fill in the else block at the
end.
public class Cup extends GamePiece
{
public Cup(Owner ownerIn, GamePiece parentIn) throws Exception
{
if(parentIn == null)
throw new Exception("Uh-oh");
else
{
}
}
}
7. Write a method for the GamePiece class to return the ownership value. When writing the
method, you can assume that all of the pieces of machinery mentioned in the general information
given above is in place. This will make the code relatively short and sweet. You don't have to
test for things like whether or not the structure is a tree, whether or not a node has a parent,
whether or not the root node has an owner, and so on. Notice that under the assumptions given,
when written correctly in the GamePiece class, this method could be freely inherited by its
subclasses without having to override it.
5
III. Unit 27, Ch. 25, Interpreter
8. This is one of the questions where you could write code for a complete solution. Space is not
given for a handwritten answer. Given the interpreter diagram (InterpreterDiagram.vsd,
InterpreterDiagram.docx) and the classes InterpreterClient.java, PieCommand.java,
CrustCommand.java, FillingCommand.java, and ToppingCommand.java, write the code for this
class: PieCommandSequence.java. Your code should embody the Interpreter design pattern,
but in a form simpler than that given in the book. Your code will not involve the Composite
design pattern; it will not have control structures like for, while, or if; and it will not have terms
or variables. It should be possible to compile everything cleanly and run InterpreterClient.java,
obtaining the output shown in the file output.txt. For this question you should not modify the
given code. You should simply supply additional code.
InterpreterClient
PieCommandSequence
ArrayList
PieCommand
CrustCommand
FillingCommand
ToppingCommand
/*******************************************
* Chapter 25, Complete Assignment Givens
*******************************************/
public class InterpreterClient
{
public static void main(String[] args)
{
PieCommandSequence myProgram = new PieCommandSequence();
myProgram.add(new CrustCommand());
myProgram.add(new FillingCommand());
myProgram.add(new ToppingCommand());
myProgram.execute();
}
}
public class PieCommand
{
public void execute()
{
}
}
public class FillingCommand extends PieCommand
{
6
public void execute()
{
System.out.println("Tangy Lemon Filling");
}
}
public class CrustCommand extends PieCommand
{
public void execute()
{
System.out.println("Flaky Crust");
}
}
public class ToppingCommand extends PieCommand
{
public void execute()
{
System.out.println("Luscious Meringue");
}
}
IV. Unit 28, Ch. 29, Visitor
9. This is one of the questions where you could write code for a complete solution. Space is not
given for a handwritten answer. Given the interface MachineVisitor.java and the classes
VisitorClient.java, Machine.java, MachineComponent.java, MachineComposite.java, and
NameReversedVisitor.java, you will find that as they stand you can't get a clean compile of
everything. You should make the changes to the given code necessary so that it will correctly
embody the Visitor design pattern. After making the changes it should be possible to compile
everything cleanly and run VisitorClient.java, obtaining the output shown in the file output.txt.
For this question you modify the given code.
/*******************************************
* Chapter 29, Complete Assignment Givens
*******************************************/
public class VisitorClient
{
public static void main(String[] args)
{
Machine myMachine = new Machine("Example Machine");
NameReversedVisitor myVisitor = new NameReversedVisitor();
myMachine.accept(myVisitor);
}
}
public interface MachineVisitor
{
public void visit(Machine m);
7
public void visit(MachineComposite mComposite);
}
public abstract class MachineComponent
{
public void accept(MachineVisitor v)
{
v.visit(this);
}
}
public class Machine extends MachineComponent
{
String name;
public Machine(String nameIn)
{
name = nameIn;
}
public void setName(String nameIn)
{
name = nameIn;
}
public String getName()
{
return name;
}
}
public class MachineComposite extends MachineComponent
{
}
public class NameReversedVisitor implements MachineVisitor
{
public void getNameReversed(MachineComponent mc)
{
mc.accept(this);
}
public void visit(Machine m)
{
String name = m.getName();
String revName = "";
for(int i = name.length() - 1; i >= 0; i--)
{
revName = revName + name.substring(i, i + 1);
}
System.out.println(revName);
}
8
public void visit(MachineComposite machineCompositeIn)
{
/* You do not have to worry about this part of the code.
For the purposes of this example you are only interested in
the code for Machine, not MachineComposite(). */
}
}
V. Unit 30, Ch. 9, Observer
Let this UML diagram be given.
Observable
«interface»Observer
+addObserver(o:Observer)()
+notifyObservers()()
+setChanged()()
+update(o:Observable, arg:Object)()
Cup
-seedCount : int
MyPanel
-aCup : Cup
10. Refer ahead to the next question for information that might be helpful in answering this
question. Provide the correct parameter in the call to the Cup constructor inside the MyPanel
constructor. Notice that this parameter is critical to the functioning of MyPanel as an observer of
Cup.
public class MyPanel implements Observer
{
private Cup myCup;
public MyPanel()
{
myCup = new Cup(___________);
}
11. Provide the one line of code needed to complete the implementation of the Cup class
constructor. Notice that this is critical to the functioning of Cup as an observable class.
public class Cup extends Observable
{
private int seedCount;
public Cup(Observer observerIn)
{
______________________________________________________________________;
}
9
12. Write a setSeedCount() method for the Cup class.
VI. Unit 31, Ch. 19, Memento
The book's example for the Memento design pattern was a graphical application that
displayed standard icon images of machines in a work area. They could be added and clicked
and dragged around. The book's code included these data structures: A List (in practice an
ArrayList) and a Stack. It also included menu options "Save As…" and "Restore From…".
13. Describe what was stored in the elements of the ArrayList.
14. Describe what was stored in the elements of the Stack.
15. Assuming that the application was not in the initial, empty state, describe what happened
when the "Restore From…" menu option was taken. Your answer should explain what happened
to the contents of the Stack and the contents of the ArrayList.