Part 3: Huckle Buckle Beanstalk!
8) (4 marks) Initial steps: Import v1 of the Huckle Buckle Beanstalk codebase (hbbv1.jar
) into Eclipse, then compile and run it with no command-line arguments. Note that this jar contains source code – it must be compiled before it will execute. If your import is successful, a series of lines should be printed to the Eclipse console, starting with Playing HuckleBuckle on a 5 by 5 grid...
Examine the code in hbbv1, to see how it implements each of the elements in the class diagram below.
Figure 1. Class diagram for hbbv1.
Now read about “Creating Jar Files” in the Eclipse documentation. Please note that the default jarfile created by Eclipse contains source code, and is not directly executable. It is somewhat more complicated to create what Eclipse calls a “runnable JAR” and which Oracle calls an “executable JAR”; you have seen an example of an executable JAR in Part 2. You are not required to create an executable JAR in this assignment, however you should confirm that hbbv1.jar is not runnable on your platform (for example, it won’t do anything if you doubleclick
On it).
Now create a new project called hbbv1.1. You’ll be using this project to create a new minor version, and it’s a good idea to keep a copy of all previous released versions of a code – normally you’d do this in a source code repository but using a repository is out of scope for this assignment.
Import all the source code from hbbv1.jar into your hbbv1.1 project. Note: you could drag-and-drop files from your hbbv1 project using Eclipse’s package manager, but you might drop the files in an incorrect place -- so it is safer to use Eclipse’s Import functionality whenever you are adding resources (source code, graphic images, etc.) to a project. Change the VERSION number to “1.1”. Make sure you can compile and run hbbv1.1 without errors. Note that you will have multiple Run configurations in your Eclipse workspace, so you’ll have to be careful to run hbbv1.1 rather than hbbv1, and you should confirm that you’re running version 1.1 by looking at
the first line of console output.
For assessment:
Add the following paragraphs to the documentation comment for HuckleBuckle.java:
* <p>
* Second optional command-line parameter: ngames, the number of games to be
* played on this run of the program, an integer between 0 and 9 inclusive.
* Note: if only one command-line parameter is supplied, it is interpreted as
* gridsize rather than as ngames, as indicated by the nested bracketing
9
* on the usage comment below.
* <p>
* Usage: hbbv1.1 [gridsize [ngames]]
Now adjust the code in hbbv1.1 so that it implements the change described above. Note that you won’t be able to do this until you understand how the main() of v1.0 was testing args.length and what is happening when it executes Integer.parseInt(args[0]). You may ask anyone for assistance in understanding the code in hbbv1.0, but your work on hbbv1.1 must be independent because it will be assessed.
Your submission on this question should be
a listing (that is, a human-readable rendition) of your source code for main() of hbbv1.1,
a listing of your source code for the method in which you have added a looping construct (perhaps a forloop) with ngames as a parameter,
a listing of the console output produced by a run of hbbv1.1 with command-line arguments 3 2, and a listing of the console output produced by a run of hbbv1.1 with command-line arguments 4 0.
To receive full marks, your console output must tell an understandable story about Sally playing with Harry – so you should insert code to make Sally say additional things (perhaps “Let’s play again!” or “No, thanks, not this time.”) at appropriate times.
9) (4 marks) Initial steps: Examine the implementation of seek(), and look for repetitive code sequences in this code. You may eventually notice that there are two if() statements that have a very similar structure: the seeker’s current position (obtained via a getter) is compared to their next position, and if there is any difference then the seeker is moved to this new position (using a setter), the distanceMoved variable is updated, and the new position is reported to the console.
For assessment:
Create a new project called hbbv1.2, with a copy of your hbbv1.1 codebase. Add a new method to the Seeker class, so that the seek() method can be implemented in a simpler fashion, without repetitive if() statements.
The new method should be called moveTo(), and your new implementation of seek() should include the following lines of code:
for (int y = 0; y < getGame().getGridSize(); y++) {
for (int cx = 0; cx < getGame().getGridSize(); cx++) {
// cx: counts the number of times I have moved on row y
int x = (moveRight ? cx : getGame().getGridSize() - cx - 1);
moveTo(x,y);
Note that a v1.2 Seeker can use her moveTo() method to move to any position on the grid. Accordingly, your implementation of moveTo() should increase distanceMoved by the number of steps a seeker must take to get to a new square on the grid; and if the seeker is already at this new position, then she shouldn’t report it. You need not check for illegal (out of range) positions on the grid; we’ll discuss such issues in the code quality theme
of the course.
You’ll need a distance() function; to keep things simple you might be tempted to copy a private distance() method you’ll find in the current implementation of the Hider, but to keep the code “simple” (and to receive full marks) you should shift the Hider’s distance() method into the Player class so that the Seeker can use it too, and so you’re not duplicating code.
The process of “cleaning up code” by “pulling a method up to its superclass” (as you have done with distance() in this question), by “extracting” lines of code into a new method (as you have done with moveTo()), or by any other method, is called re-factoring. Recognising a situation where a re-factoring would be helpful is a very important skill in programming, but it’s quite an advanced skill – and I won’t be covering the full range of refactoring operations in this course! However you should look at the submenu under Refactor in the Java perspective of Eclipse, to get a sense of the variety of refactoring operations that are important enough and which are simple enough – to be partly-automated by Eclipse. I do not encourage you to use the refactoring
support that is available in Eclipse until you are able to refactor without its support, but I hope you can see (after completing this question) that it’d be pretty easy to introduce a bug into a program when you’re refactoring it, and that there’s a lot of repetitive work to be done when you’re refactoring code, so gaining fluency with an IDE’s refactoring support is a very important skill for a “production programmer”!
Submit: a listing of your revised Seeker class (so that your marker can assess your revisions to seek() and your implementation of moveTo()).
Figure 2. Class diagram for V1.3 of HuckleBuckle.
For assessment:
Produce Version 1.3 of the HuckleBuckle codebase. In this version, main() should read its arguments, instantiate a hider named Harry and a seeker named Sally, then invoke Harry’s pleasePlayWith() method (so that Harry will play zero or more games with Sally). Harry’s pleasePlayWith() method should be implemented with code which causes him to invoke Sally’s pleasePlayWith() method – this causes Sally to play a single game of HuckleBuckle. Note that Sally’s pleasePlayWith() method is essentially the same as her seek() method in earlier versions, but its references to the current game must be adjusted. Sally will eventually find the hidden object, and Harry will “notice” this event when he receives a (void) result from his call to s.pleasePlayWith(this, new Game(gridSize)). Harry’s pleasePlayWith() method should then decrement his nGames counter, and (depending on whether or not the counter has reached 0) this method should either exit or ask Sally to play another game (after Harry “hides” another object).
Submit:
listings of all classes in hbbv1.3,
a sample of its output (for commandline arguments 5 2), and
a jarfile containing your source code for hbbv1.3.
