| ITEC 120 |
| 2007spring |
| ibarland, jpittges |
|
|
|
home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs
We will spend 5min showing a function which returns a boolean.
Work on today's lab with a partner. You can write the following two-to-three methods in a class named, say, ebayExpert.
If you sell an item on eBay, you are charged a fee. That fee partly depends on how much the item sold for (its “sale price”); there is also a flat fee just for using eBay to start with, as well as an optional extra fee if you want some fancy pictures in your listing. More precisely, eBay's fee structure is1:
Write a function computeEbayFee, so that eBay knows how much to charge each seller, when an auction finishes.
In your test cases, you noticed that if the item sold for a small price,
the ebay fee can actually exceed what the item sold for, and the seller
actually lost money on the auction (!).
Write a function wasAuctionProfitable,
which returns a boolean:
it returns true if the seller made a penny or more,
and it returns false if the seller lost money (or broke even).
There is nothing particularly special about the fact that the return type
is boolean;
you can look at the
example from lecture,
mustRegisterForDraft.
We want this function to work — without modification — even if eBay totally revamps their pricing structure. (That would require rewriting ebaySellerFee, but it shouldn't require rewriting wasAuctionProfitable. Yay, for no repeated code!)
Of course, as per The Design Recipe, we want the function's signature, javadoc comments, and test cases, as well as the body of the function.
Look back at your computeEbayFee program, above. Show yours to another group, and have a look at their version. Is their code easy to understand? Do they think your code is clear?
Using local variables to name sub-parts of your overall answer can be very helpful. But even as it is, there are a bunch of wild numbers (like 0.35 and 0.03 and 25.00) cavorting about. The only way a stranger would know what those numbers meant is if they had already inspected the eBay fee tables closely, and had memorized them.
This is where named constants can help, as introduced in the lecture example highwayDrivingTime. Named constants are similar to local variables, but with an important conceptual difference:
The value assigned to named constants is known before they are ever used (unlike local variables, where the exact value depends on the function's parameters).There is a convention for named constants: write them in ALL_CAPS. That way other programmers can tell right away that a certain variable is a constant.
computeEbayFee is crying out for its constants to be named. Go back and modify computeEbayFee so that all the fee-structure comments are named constants.
double computeEbayFee( double salePrice, boolean hasGallery ) {
double THRESHOLD1 = 25.00; // How much of the salePrice is subject to COMMISION1.
double COMMISION1 = 0.0525; // The commision for the first THRESHOLD1 dollars of salePrice.
double GALLERY_FEE = 0.35; // A flat fee for starting any listing at all.
// ...
}
|
Expect homework/exam questions like “How are named constants written differently from local variables?” and “Conceptually, how is a named constant different from a local variable?”, and/or some examples of code asking you to attach a name to some value.
If you finish writing and testing the above functions, there's one more interesting twist to consider.
The above problem was simplified a bit;
eBay's final-value-fee doesn't have just the two tiers
(0.00, 25.00] and (25.00, ∞),
but actually three: (0.00,25.00], (25.00,1000.00], and (1000.00,∞).
Those round and square parentheses are math-ese for intervals with open and
closed endpoints; eBay presents this same information
in a table.
Go back and change your program to use eBay's actual final-value-fee.
Java tip: We said that you can put any statements you like inside the curly-braces of an if-else statement, even other if-else statements! Try using the following skeleton:
if ( /* test for being in the bottom tier */ ) {
/* Compute the bottom-tier-price */
}
else { // we're not in the bottom tier, so ...
if ( /* test for being in the middle tier */ ) {
/* Compute middle-tier-price */
}
else { // we're not in the bottom nor middle tier, so ...
/* Compute top-tier-price */
}
}
|
This pattern of nested if statements is common enough that Java included a prettier way of writing the same thing: the if-else-if statement, which we'll talk about in tomorrow's lecture.
1 We are simplifying the problem a bit: we assume that your starting price is a penny — really, eBay should allow for the starting price of zero, if you ask me — and for our purposes we slightly simplify the final value fee. See the challenge problem, below. ↩
home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs
| ©2007, Ian Barland, Radford University Last modified 2007.Aug.27 (Mon) |
Please mail any suggestions (incl. typos, broken links) to iba�rland  rad�ford.edu |
 |