Instructions

1. The examination is open book/notes.  You are allowed to consult any written materials available under the sun that was published or posted before the start of the exam, except code from your current Comp201 classmates.  If your code is based on materials that we did not provide you, just give us the appropriate references.
2. You are not allowed to discuss the exam in any way with anybody beside the instructors
of this course (i..e. Dr. Wong, but not the labbies) .
3. If you have questions, use the Owlspace exam chat rooms, AIM or Windows Live (MSN) Messenger during the designated times or e-mail  swong@rice.edu your questions instead. We will reply to you directly, and if deemed necessary, we will forward our reply to the public Owlspace chat room as well.  We will check our e-mail as often as we can to catch and respond to your questions.  The instructor's MSN and AIM username will be e-mailed to you separately before the exam.
4. Check the public Owlspace chat room for any announcements of typographical errors or clarifications!
5. Write your code in the most object-oriented way possible, that is with the fewest number of control statements and no checking of the states and class types of the objects involved in any way.
6. You have 4 hours to do the regular questions on the exam once you begin reading it.
7. Submission instruction: you must submit your exam in two ways.
   •  a hard copy with all answers in typewritten form, except perhaps diagrams (if any) which can be hand-drawn.  Be sure to print your name and sign the honor pledge.  You do not need to print out the supplied code unless you have modified it.
   • Zip your work together with your honor pledge (included in the provided code) and upload to the Owlspace upload page under "Exam 2". 
8. The deadline for submission is  Mon. April 9, 2007 @ 10:00 AM.

Download the provided code: exam2s07.zip, which contains all the exam materials in a directory called exam2s07.   Each question has its own project, perhaps multiple projects for the different sub-sections.

• Put all the code for each problem in its respective subdirectory, e.g. Prob1, Prob2, etc.

• Your code is required to pass the supplied test code!

• Zip up the entire exam2s07 directory including the filled-out Honor Code file and hand it in using the usual upload page.

PRINT THIS PAGE AND ALL YOUR CODE, WRITE AND SIGN YOUR HONOR PLEDGE AND BRING IT TO CLASS ON THE DUE DATE.

Problem 1: A Model Roommate with State (30 pts total)

Let's consider a model of a roommate.  As we all know, roommates behave differently in different circumstances and how they behave can change almost instantaneously.     Suppose we had a class that modeled a roommate. 

We'll use a simplified representation of a roommate where the following features apply:

• The roommate has an eye color, which is needed to instantiate the class and for which there is a gettor method.
• .The roommate has a getGreeting() method that returns the String the one would hear from the roommate at that time.
• The roommate has an eat() method that reproduces the effects on the roommate of eating some food.
• The roommate has an study() method that takes the number of hours studied as an input parameter.  This method may also affect the behavior of the roommate.

The test code below may thus be a reasonable approximation on how our roommate behaves during a sequence of actions:

Roommate rm = new Roommate(Color.BLUE);

assertEquals("Eye color", Color.BLUE, rm.getEyeColor());
assertEquals("Greeting, initial", "Zzzzzzz....", rm.getGreeting());
assertEquals("Greeting, second time after initial.", "Go away!", rm.getGreeting());
assertEquals("Greeting, third time after initial.", "Go away!", rm.getGreeting());
rm.study(1);
assertEquals("Greeting, after 1 hour study", "Go away!", rm.getGreeting());
rm.study(40);
assertEquals("Greeting, after 40 hours study", "Go away!", rm.getGreeting());
rm.eat();
assertEquals("Greeting, after eat.", "What a great day!", rm.getGreeting());
assertEquals("Eye color", Color.BLUE, rm.getEyeColor());
rm.eat();
assertEquals("Greeting, after eat again.", "Huh? Where am I?", rm.getGreeting());
rm.eat();
assertEquals("Greeting, after eat third time", "Zzzzzzz....", rm.getGreeting());
assertEquals("Greeting, again", "Go away!", rm.getGreeting());
rm.eat();
assertEquals("Greeting, after eat.", "What a great day!", rm.getGreeting());
rm.study(3);
assertEquals("Greeting, after 3 hours study.", "What a great day!", rm.getGreeting());
rm.study(4);
assertEquals("Greeting, after 4 hours study.", "Huh? Where am I?", rm.getGreeting());
assertEquals("Eye color", Color.BLUE, rm.getEyeColor());

 From the above sequence interactions with a Roommate object, it is clear that the Roommate object changes its behavior dynamically.  This dynamic change of behavior can be implemented using the state design pattern.

Problem 1.a:   (5 pts) What depends on the state?

Of the methods of the Roommate class, getEyeColor(), eat(), getGreeting() and study(), which depend on the state of the roommate?   Explain your reasoning.

Write your answers in the comments section of the Roommate.java file.

Problem 1.b:  (5 pts) The States of a Roommate: 

From the above test code, how many states do your think a Roommate has?   Describe the states.

Write your answers in the comments section of the Roommate.java file.

Problem 1.c.   (5 pts) Roommate's fields and abstract state:   To start, start completing the code for Roommate.java as per the instructions below.

• Figure out what fields the Roommate class must have and implement them.
• Figure out what methods the nested abstract state class, AState, must have order for it to properly represent the union of all the concrete states and write their declarations.   Minimize the number of input parameters to these methods!
• Implement the public methods and constructor of Roommate.

Problem 1.d (15 pts)  Concrete States:  

Implement the concrete states of Roommate using anonymous inner classes and initialize the current state of the Roommate, _state, to its proper value.

Suggestion:  Before you start writing any code, on a piece of paper, using the information from the above test code, draw the state diagram of Roommate that shows the states of the system, the transitions from state to state and what methods cause those transitions.  

Notes::

• No additional methods should be added to the Roommate class.   Additional fields are acceptable.
• No additional classes or interfaces may be added that are visible from outside of the Roommate class.
• By properly using the closure of the anonymous inner classes, minimize the number of input parameters that passed.
• At most, a single if-statement is only used in only one method.

Problem 2:  A Better Zipper (25 pts total)

Problem 3:  A Better 3-Way Switch (45 pts total)

In the last exam, we implemented a 3-way switch system.     This system consisted of a couple of different types of switches and wires as well as a battery (which was really just a wire with a fixed voltage on it).  But there were several problems with the code:

• The states of the two 2-way switches, One2TwoSwitch and Two2OneSwitch, were not fully encapsulated and hidden away inside those respective classes.   Instead, they were implemented as package-visible classes that any class in the elec package could use.
• The two specialty wire implementations, SwitchDownWire and SwitchUpWire, are really just hacks to enable use to create a wire that specifically ties to either the up and down voltage output of the One2TwoSwitch class.   All these wires do is to connect particular terminals on the switch to any other electrical component in the system.

But we are now better armed with the notions of the State and Factory Design Patterns as well as anonymous inner classes.   So let's improve out existing code to take advantage of our new knowledge.

Problem 3.a (15 pts): Anonymous States:   First, we will need to fix the State Pattern implementation in the two 2-way switches.

Using the stub code that has been provided,  fix the implementation of Two2OneSwitch by creating a new class BetterTwo2OneSwitch that has the following features:

• There are no state-related classes visible from outside of BetterTwo2OneSwitch.    This includes the abstract state class and any concrete implementations of that abstract state.
• All concrete states are represented as anonymous inner classes.
• None of the methods of the internal states have any input parameters.   All necessary variable or field references should be obtained via the closure of the anonymous inner class used to implement the concrete state.
• No method of BetterTwo2OneSwitch ever instantiates a state.
• Your code should pass the supplied test code.

Problem 3.b (10 pts):  More Anonymous States:   Under the same constraints as above, re-implement the State Design Pattern in One2TwoSwitch.   Use the supplied stub code in the BetterOne2TwoSwitch class to complete your redesign.   The test code is combined with that for the next section.

If you cannot get Problem 3.a to work properly, copy the State pattern code from One2TwoSwitch to BetterOne2TwoSwitch and leave this problem for after Problem 3.c!

Problem 3.c (15 pts): Wire Factories:   To get rid of those annoying special wire classes,  SwitchDownWire and SwitchUpWire, we re-examine the output of the One2TwoSwitch class.    Comparing to the Two2OneSwitch class, we see that in that class, the switch's output appears as an IWire because the switch implements the IWire interface.   That is, the output of the switch is actually a wire through which one can obtain a voltage, not just a bare voltage output.   Turning back to One2TwoSwitch, we see that this is not the case here.   One2TwoSwitch does not implement the IWire interface, so its output is two bare voltages, not wires. 

Ah, but here's the rub:  an IWire implementation is only capable of outputting a single voltage value, which works fine for Two2OneSwitch because it only has one wire coming out.   But One2TwoSwitch has two different outputs, an "up" wire and a "down" wire that behave quite differently--that is, it appears to implement the IWire interface twice!     How can a class effectively implement an interface twice and have different behaviors for those two implementations?

(Drum roll, please!)  Factories to the rescue!   We don't want two methods on One2TwoSwitch that give us voltages--we want two methods on One2TwoSwitch  that give us wires.   In effect, we want to have One2TwoSwitch factory those two specialized wires that are used to connect it to other electrical entities.

You are to re-design and re-write the getVoltageUp() and getVoltageDown() methods of One2TwoSwitch so they return IWires whose getVoltage() methods return the voltage from their respective wires.  These methods are renamed getVoltageUpWire() and getVoltageDownWire() respectively in the supplied BetterOne2TwoSwitch stub code.

Be careful!  Remember that the output voltage depends on the state of the switch!

Your code should pass all unit tests.

Problem 3.d (5 pts): Putting it all together into a better 3-way switch:   In the constructor of the supplied class BetterThreeWaySwitch, insert coded  modified from the constructor of ThreeWaySwitch to use the better two-way switch implementations.     Your code should pass all unit tests.

Last Revised Thursday, 03-Jun-2010 09:50:25 CDT

©2008 Stephen Wong and Dung Nguyen