ITEC 120 2007fall ibarland, jdymacek

home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs

hw10
Interactive Explorers
I/O

lack of automated tests: Because I/O makes for difficult testing (often there is no predictable result to assertEquals in unit tests) so you don't need to turn in any unit tests for this homework. You will turn in your code and documentation together in class on Oct.31 (halloWednesday). (Of course, you'll still be running (However, it's possible to still make unit tests which read input from a fixed String, and you can inspect the terminal window manually.)

1. Copy your hw08 (as polished in lab09b and with any improvements you made in response to your graded hw08) to a new project, for this homework.

2. We will write a class TextIO, which will help communicate between your explorer's world and somebody playing the game.

   1. A TextIO instance will have one private field (with no getters or setters): a Scanner, which it uses to read all its input from. Make a constructor which takes no arguments. The textIO object will use a Scanner created from the keyboard (System.in).
      The TextIO objects you make with this constructor are great for using interactively, but aren't helpful for testing (since every time you (re)run a test, you'll have to type at the keyboard).

   2. Make a second (“overloaded”) constructor, which takes one argument — the Scanner this TextIO will read from.

      This variant will be very handy for testing -- you can make a new TextIO( new Scanner( "chill inventory dude" ) ), and then test the methods below without having to type input from the keyboard every time.¹ (This explanation will make more sense after you've finished the parts below.)

3. Write the following method, for TextIO:

   /** Display game info to the player. * @param msg The message to display. */ public void display( String msg )

   This is a very simple method — so simple you might wonder why we even have it, instead of printing to the screen directly. We'll see later how this indirection gains us flexibility.

4. Write the following method, for TextIO:

   /** Print a message to the screen, and get a response. * @param msg A message to print to the screen, * for example "What month is your birthday? ". * @return The response -- just one word, which is taken * from this TextIO's internal Scanner. (If this Scanner happens * to be reading from System.in, then this function is getting * an answer interactively.) * Example: String myFave = someIO.promptForString( "What month is yer bday?" ); * */ public String promptForString( String msg )

   Rationale: As seen in lab10b—input: Scanner, a common bit of code is to (a) print some information on the screen, and then (b) immediately use a scanner to read an answer. In fact, these two tasks are so often done together that it's convenient to be able to do that with one single method call. For example, instead of writing²

   System.out.print( "Enter a celsius temperature: " ); myLocalVar = myScannerObject.nextInt();

   it would be nicer to only have to write

   myLocalVar = myTextIoObject.promptForInt( "Enter a celsius temperature:" );

   With TextIO, we buy ourselves that convenience; it will be a handy class for any future project.

5. Write a method promptForInt, analogous to promptForString.

6. Write a method exploreOnce, inside of class Explorer. This method will

   1. make a new TextIO,
   2. prompt the user to type a command, and
   3. handle that command as follows:
      • if the user typed “inv”, call the method inventory and display the result;
      • if the user typed “drop-left” then call dropLeft and display the result;
      • likewise for “drop-right”
      • if the user typed “help” then display a listing of the allowed commands.
      • if the user typed “chill”³ then display “You feel very relaxed.”
        (You can use a different word and response, but please keep it clean.) You can leave this as an easter egg not reported by “help”.
      • Otherwise display “I don't know what you're talking about.”

      This method should only communicate with the user via methods in TextIO; this method must not call System.out.println directly.

      preview: Later, you'll be provided with a class GuiIO, which has exactly the same methods as TextIO, but it uses a GUI window rather than the console and keyboard. But your explorer program should run equally well if you use the GuiIO in place of the TextIO. That is why your exploreOnce method doesn't interact directly with the keyboard or screen.

7. Paste in the following method to your Explorer class:

   public static void main( String[] ignored ) { Explorer hero = new Explorer( "Dora" ); hero.exploreOnce(); hero.exploreOnce(); hero.exploreOnce(); }

   This is a bit like a test-driver (although we haven't yet explained what the [] in String[] means). After making this “main” method with this exact signature, it's now possible to:
   1. Actually run your program from eclipse: choose Run > Run As... > Java Application.
   2. make a stand-alone file you can double-click on: from BlueJ, choose Project > Create jar file..., selecting Explorer as the main class. (You don't need to include any libraries.)

8. Some extra credit: As it stands, we have two different TextIO constructors. This is a bit bothersome, since if we ever add more statements to one of those constructors in the future, we'll have to remember that we probably want to add those same statements in the other constructor as well. It would be better to not have to repeat such code. (And in fact, there is a smidgen of repeated code as-is: assigning to the field.)

   Read about using this with a constructor to see how one constructor can call another. Then, modify one of your existing constructors so that it's just a single line which calls the other constructor.

home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs

©2007, Ian Barland, Radford University Last modified 2007.Nov.11 (Sun)

Please mail any suggestions (incl. typos, broken links) to iba�rlandrad�ford.edu