ITEC120-ibarland—info—lectures—labs

passing booleans; overloading functions

Oct.11 (Wed.): For this lab, work individually. Check off your work before you leave lab, or at the start of lab on Friday.

Back in an early lab, we wrote a couple of methods for computing tax. The method priceAfterTax added sales tax to an item, which often is the correct thing to do, but not always: Some times (food) are tax-free. Some times there are tax-free shopping days for back-to-school supplies. There might be other obscure situations where tax doesn't need to be added (internet purchases which are shipped out-of-state, perhaps).

So: We want to improve our original priceAfterTax function so that it takes a second input, in addition to the purchase price: it will accept a boolean value isTaxable, and will compute the final price (which may or may not include tax, depending on whether the caller passed in true or false).

1. First, take our original TaxMan class, and add the keyword static to the methods and fields. (We were effectively using them as static back in week one; we just didn't know that word back then.)
2. Leaving the existing method priceAfterTax intact, write another method which is also named priceAfterTax but it takes the list price and a boolean value isTaxable. (As always, be sure to provide the javadoc comments, and test your function.) You won't need to touch salesTaxOn.
   Test your method both from BlueJ's pop-up menu, as well as from the code pane:

   TaxMan.priceAfterTax(100, false) == 100 // A non-taxable $100 item. TaxMan.priceAfterTax(100, true) == 105 // A taxable $100 item. TaxMan.priceAfterTax(100, (100 > 25)) == 105 /* If we had a method todayIsATaxFreeDay(), you could imagine * that clothing and school supplies might call something like * TaxMan.priceAfterTax(100, todayIsATaxFreeDay() ); */ TaxMan.priceAfterTax(100) == 105 // We didn't break our old code.

   (Notice how we call a static method by mentioning the class-name before the dot, rather than walking up to some particular TaxMan instance; after all, “static” means that the method is associated with the class, not with individual instances. This is exactly what happens when we called Math.sqrt and Math.floor and Math.PI, which are static methods/fields inside the Math class.)

Interestingly, it's no problem having two versions of priceAfterTax in the same class. Even though they have the same name, when somebody calls one of them, Java can distinguish which one of the two functions is intended by looking at the two signatures (do they pass a double, or a double-and-a-boolean?).

3. This is all neat, but: We might have repeated code, between the two versions of this method. If so, change one so that it calls the other. (You may or may not rewrite the original one-argument version so that it now calls our more general two-argument version.) Test to make sure that both versions still pass their test cases.
4. Optional challenge: The sales tax on most items is 5%, and that covers most cases. However, occasionally somebody might want tax computed with a different tax rate: 3% for cars, or other rates, for items sold in other states¹
   Write a second version of salesTaxOn which accepts any desired tax rate. When you have finished documenting, writing, and testing that version, get rid of duplicate code (don't multiply a list-price by a tax-rate in two different places): Have your original salesTaxOn call your new version, passing it the standard Virginia sales tax rate of 5%.
   Finally, write a third version of priceAfterTax which takes a third input: the specialized tax rate. Have your two-argument version call the three-argument version, again using the state's standard sales tax as the default.

It is called overloading a method, when you have two different versions which both have the same name. You must be able to distinguish them just by the input types; Java doesn't use the return type (partly because it does so much auto-converting of things to Strings behind-the-scene).

Overloading is convenient, but it isn't a deep concept: if Java didn't happen to provide it for us, we could still get the same effect just by giving slightly different names to each function (“salesTax_isTaxable”, “salesTax_isTaxable_taxrate”, etc.). After all, when somebody is writing code which calls one version or the other, they know at that moment which arguments they want to pass in, so they'd know which version to call even if they had different names.
Overloading just lets us avoid having to think up and remember several similar names.

Today we will check off TaxMan if you haven't already, and discuss and work on writing last week's PairODice well.

• General spacing and readability. In particular, leave a blank line or two between the end of one method and the start of (the comments of) the next method. Put spaces inbetween “if” and the condition's “(”, and similarly a space after the condition before the opening “{”.
  (This is the same reason people put a blank line between paragraphs, and between words.)
• Does PairODice.toString call Die.toString? If not, you have a lot of repeated code.
• Remember, Die.getFace() returns the face without rolling the die. Die.roll() does roll the die, you shouldn't call this method from most of your code.
• Some issues in PairODice.nameOfRoll (most-important first):
  1. Does your indentation of if-else-if match what was suggested in lecture, down to each bracket and parenthesis?
  2. How to slickly detect doubles and return a correct string, in a single if test?
  3. Consider creating local variables like f1 to remember the value of die1.getFace().

ITEC120-ibarland—info—lectures—labs

©2006, Ian Barland, Radford University Last modified 2006.Oct.13 (Fri)

Please mail any suggestions (incl. typos, broken links) to ibarlandradford.edu