home—info—lects—labs—exams—hws
tutor/PIs—breeze (snow day)
Object120 + its docs—java.lang docs—java.util docs
hw07
Explorers
I/O, a first loop
Due Oct.29 (Mon) 23:59;
submit on D2L and bring hardcopy to the following class.
For this homework, we will
create a class that represents an explorer in a simple game.
(Later, we might make a single program which uses both explorer and treasures.)
Although many methods are required, almost all of them are just one or two lines of code.
Do include:
javadoc documentation,
and
at least one test case for each function, unless otherwise specified.
(These, along with a non-working stub function,
get you 50% of the points or more.)
Make all methods non-static, when possible.
- (5pts) Define a class Explorer.
Every explorer will have the following information:
a name (e.g. "Dora"),
a status (e.g. "is eager to start adventuring." or "sees nothing of interest."),
whether or not they are ready to retire,
and a hunger-level (a number indicating how hungry they are).
(Make sure your code compiles and runs, before continuing.)
- (4pts)
Write a standard constructor (which takes in exactly as many parameters as there are
fields1).
(Make sure your code compiles and runs, before continuing.)
-
(5pts)
Write a looksEqual method, compares two explorers and returns whether
all the corresponding fields have the same values.
Make this method non-static.
Include two test cases, calling assertEqualBooleans.
Write a static method assertExplorersLookEqual2,
which takes in two Explorers,
and does nothing if they look equal,
but prints an error message if they don't.
You do not need test cases for this.
(Make sure your code compiles and runs, before continuing.)
- (5pts)
Write a static function createNewExplorer which takes in just a name,
and returns a brand new explorer with appropriate initial-values.
(Be able to answer to yourself: why does this method need to be static?)
Be sure to write one test case before you write this method;
presumably that test will use assertExplorersLookEqual
to verify the created-explorer actually looks like the result you desire.
(Make sure your code compiles and runs, before continuing.)
- (5pts)
Write a public String toString( /* Explorer this */ ) method,
which returns a string with the explorer's name and hunger-level (but not their status),
and (only as appropriate) a statement saying they are ready to retire.
This string should be appropriate for an end-user (not necessarily a programmer) to read.
Your test case will call assertEqualStrings.
(Make sure your code compiles and runs, before continuing.)
- (5pts)
Write a method void eat( /* Explorer this */ ), which decreases the explorer's hunger level,
and sets their status to something like
“enjoyed a tasty snack”.
Remember that when testing void methods,
you'll first call the method,
and then either: (a) call assertEqualInts
on the hunger-level and assertEqualStrings
on the status,
or (b) make one call to assertExplorersLookEqual,
comparing the modified Explorer to a new one.
(This second approach is actually better
when copying/pasting for all these
functions we have in this assignmnet.)
(Make sure your code compiles and runs, before continuing.)
- (5pts)
Write a method void waitAround( /* Explorer this */ ), which increases the explorer's hunger level.
If their hunger level is now very high, it sets their status to “is a mite peckish.”,
otherwise it sets the status to “is bored.”.
(If you want to include the explorer's hunger-level in the resulting status,
that's fine.)
-
We might eventually have ways for an explorer to interact with the world around them,
but that will have to wait since we don't yet have any classes to represent the world around them!
However, we will set up a framework suitable for future expansion.
(8pts)
Write Explorer methods:
-
void look( /* Explorer this */ ), which just sets this Explorer's status to something like
“doesn't see anything of interest.”;
-
void grab( /* Explorer this */ ), which just sets this Explorer's status to something like
“finds nothing to grab.”;
-
void quit( /* Explorer this */ ), which just sets this Explorer's status to something like
“is fed up with adventuring.”,
and sets readyToRetire to true.
-
void help( /* Explorer this */ ), which just sets this Explorer's status to something like
“knows how to: look, grab, wait, eat, quit, help.”.
-
(5pts)
Write a function void handleOneCommand( /* Explorer this, */ String cmd),
which is passed in one String.
If the string is one of {"look", "grab", "eat", "wait", "help"},
then call the corresponding method for this Explorer.
If a different string is passed in,
set this Explorer's status to “doesn't know how to cmd.”.
(Use one big, straightforward if-else-if3.)
You need only include 2 tests for this function4.
Those tests should be pretty easy, since if you pass in (say) "look",
you'll then copy/paste the same test you used for look() above.
Note: this function does not read anything from the keyboard!
(See the next function, for that.)
-
(5pts)
Finally, putting it all together:
Write a method public static5 void main(),
which
prompts the user to type in a name and reads it; creates an explorer with that name;
and then does the following, so long as they aren't ready to retire:
-
Prompt the user to type in a command;
-
actually get a string from the keyboard;
-
handle that one command (by calling your function above);
-
Print out the explorer's name and current status is,
e.g. “Dora is a mite peckish.”.
Note that the above description asks to do three things initially,
and then repeatedly do four things.
This means that your code will have approximately three lines,
followed by a loop whose body is four lines.
Note that you'll have one Scanner, stored in a local variable.
Here is a sample transcript from running main.
You are encouraged to phrase things your own way...
What is your Explorer-name? Coronada
Welcome, Coronada (hunger level: 0)
What do you want to do? look
Coronada doesn't see anything of interest.
What do you want to do? wait
Coronada is bored.
What do you want to do? wait
Coronada is bored.
What do you want to do? wait
Coronada is mite peckish.
What do you want to do? eat
Coronada enjoys a tasty snack.
What do you want to do? wait
Coronada is bored.
What do you want to do? gargle
Coronada doesn't know how to gargle.
What do you want to do? help
Coronada knows how to: look, grab, wait, eat, quit, help.
What do you want to do? quit
Coronada is fed up with adventuring.
Thank you for adventuring!
At this point, you are off to an awesome start to having written an entire adventure game,
which can be expanded in the future!
1More precisely: as many parameters as there are non-static fields.
↩
2If you want to just
call it assertSimilar, that's okay too.
It'll be clear from the
signature that it takes in to Explorers. ↩
3In ITEC220 and later, you'll learn
how to automate this if-else using
the “Command pattern”:
You'll keep a list of "Command" objects — each Command
object would include its own code and its own string,
and then you would loop over that list until
you found an object with the desired string.
↩
4
In a real software environment, you would want to have
at least one test per
if-else-if branch,
since conceivably each branch could contain its own,
independent bug.
↩
5Why is this method static? ↩
home—info—lects—labs—exams—hws
tutor/PIs—breeze (snow day)
Object120 + its docs—java.lang docs—java.util docs
radford.edu