ITEC 120 2007fall ibarland, jdymacek

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

lab09b
static method practice
creating lint; polishing Treasure

• Make a copy of your hw08 project. We'll make improvements to it in lab today, and you'll use this improved version in the future.
• What question do we ask ourselves, when deciding whether or not to make a method static?
• Write a method createLint, which takes no inputs and simply creates a brand new lint Treasure. What class does this belong in? Yep, it's a Treasure sort of behavior, so it should be in class Treasure. Should it be public, or private? Should this method be static? Why or why not?
• Call your method from the code pad, twice, saving the results in two local variables. Are the results ==? How do they each answer the question isLint?
  In particular, remember that the Treasure constructor checks whether the image-url is "".

• Re-write your class class Explorer to use this static method whenever new lint is required (when creating an Explorer, and when dropping the item currently in the left or right pocket).

  Re-run your tests, to make sure everything still works fine. (To think about: are your test cases good enough to catch any errors that you might have accidentally introduced? If not, then you should be writing better test cases!)

  Note that we've “re-factored” our program: it works just the same as before, but we've gotten rid of repeated code, yay!

• Hypothetically: What if we want to change lint to be spelled "lynte", for that authentic medieval atmosphere(?), and actually weigh 0.023 pounds? What two (non-test) methods would you need to change, but everything else would work perfectly?
• Clean up your existing class Treasure, with things we've learned since hw06:
  • Don't use == to compare Strings; use equals (or maybe equalsIgnoreCase, depending on what you want).
  • Make each method and field either public or private.
  • Make sure your Explorer methods call isLint as appropriate, instead of repeating the code which is already inside isLint.
  • Make sure your Explorer method toString calls inventory(), rather than repeating that code.
  • Make sure your test cases for grab and drop are comprehensive. Instead of just have a brand-new explorer drop what's in their right pocket (which was just lint) and consider your testing done¹, try dropping an item when the pocket already had lint and dropping an item when there wasn't lint in it. (How do you know whether the drop actually worked, even if the correct string was returned? Try dropping one more time!²) Similarly, grabbing items have several different situations to test: grabbing something with empty pockets, grabbing something with only one empty pocket, grabbing something with no empty pockets, grabbing a heavy items while you have empty pockets, grabbing a heavy items while you have no empty pockets. Testing for each of these situations is what you need for full testing credit.
• Write a method turnIntoGold(), which mutates a treasure so that: its weight is 100 times heavier, its name gets “Golden” added to the front of the name, its description gets “It's made of pure, 24 karat gold.” added to the end. (Its image will stay the same.)
  Should this method be static? Why or why not?
• Bonus: modify turnIntoGold so that it only changes the treasure if its name does not already start with “Golden”.

We won't be checking off this work now, but on future hws dealing with explorers, you will be marked down if your project has repeated code, compares strings using ==, etc.

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

©2007, Ian Barland, Radford University Last modified 2007.Oct.19 (Fri)

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