ITEC120

lab05:
Adding to Classes

Today will be individual work, which will be checked off either before you leave lab today, or within the first 10min of Friday's lab.

You will need to follow the javadoc guidelines, as reviewed in lab04: start comments with /**, then a description, followed by @param and @return lines, before finishing the comment with */.

Starting with the changes made last week to PizzaServer.java, paste it into BlueJ, as your starting point.

• In addition to a salary, suppose that PizzaServers also have an account balance. Add this field to the class, and add methods getBalance and setBalance.
• Optional (recommended) Update the methods asString and makeClone, to include this balance, in addition to the salary.
• Strongly suggested: Write a (static) test-method which calls these functions, in the spirit of the provided testClone.
• Add a behavior void work(double hrs), which takes the number of hours worked and adjusts the PizzaServer's balance by the appropriate amount.
  Strongly suggested: Extend your previous test function with some tests for this.
• Add a behavior String tip(double amt), which represents somebody a direct under-the-table tip which goes straight into the server's balance. The polite response is always "Thank you!".
  Strongly suggested: Extend your previous test function with some tests for this.
• Do you have repeated code in the above two methods? Factor out the common code by adding a method addToBalance, and have the methods call that instead.
  Strongly suggested: Extend your previous test function with some tests for this.
• Write a method spend, which is given a number representing how much the server spends, and adjusts the balance accordingly. (Note that conceivably, our PizzaServers might spend so much they go into debt.)
  Strongly suggested: Extend your previous test function with some tests for this.

At the start of Friday's lab, have the above functions ready to check off. When checking off your program, we will look for good indentation, meaningful variable names, javadoc, test cases (recommended to have a test function as discussed, though if you tested by hand as you went, that's okay too), and lack of repeated code.

---

The following method, which takes a PizzaServer as its parameter, has some subtleties. You can do it, but it's not required for check-off.
• Write a method void giveAll( PizzaServer aFriend ), which gives this PizzaServer's entire balance¹ to aFriend.
  Extend your previous test function with some tests for this. Here is an example of calling the function:

  new PizzaServer jo = new PizzaServer(); new PizzaServer moe = new PizzaServer(); jo.work(40); moe.work(0.5); jo.giveAll( moe );

  After these lines, jo should have a balance of zero, and that lazy good-for-nothing moocher moe should have a balance of 40.5·MINIMUM_WAGE. (What she sees in him, nobody quite knows.)

Sep.22 (Fri)

Today we'll finish writing the above functions (and get checked off on all but the last). But, we actually have a significant improvement we can make to our code. Let's pause a moment.

The method void giveAll( PizzaServer aFriend ) is a bit odd, but reasonable: Suppose we ourselves are a the giveAll expert which lives inside a PizzaServer. When called on to do our work, we are handed a different PizzaServer, to whom we'll give our money. (We choose to call that other server “aFriend”.) If we want to ask what aFriend's salary is, we can of course just walk up to them and ask: aFriend.getSalary(). We can call any of aFriend's other methods, as well.

But what happens if, in the middle of this method, we want to call our own getSalary method? The answer is a bit odd: for once, we don' put any object-reference and dot (.) ; instead we just write getSalary(). In fact, we've seen an instance calling one of its own methods from day 1 -- crustArea just calls pieArea, without walking up to any other object!

So to access our own getSalary() method, we just call it directly.

Rule: From inside a method, if an instance just calls a method without a preceding object-refence and dot (.), it is are calling its own method.²

In fact, you should do this from within most of your own methods above: rather than assign to balance directly, call getBalance and setBalance!
Why? As a single point-of-control. Imagine that the pizzeria's auditors suddenly decide that every time a server's balance is set, there needs to be a log entry printed off to some file. That's easy to do, if setBalance is the only place in the code which sets that field. All other parts of the code should call that method, rather and assign to balance directly. Similary, getBalance should be the only way for any other method to request the balance.

Your task today (Fri): Besides getBalance and setBalance, make sure no method accesses balance directly; instead use the getter and setter methods. (Similarly for the field salary.)
As you are working on this, we'll check off your code for last wednesday's portion with a √-, √, or √+ (For extreme cases, √-- and √++), according to these guidelines.

If you finish this, go ahead an try your hand at writing giveAll. (You don't need to check this off additionally, though.) If you finish that, you're free to leave!

©2006, Ian Barland, Radford University Last modified 2006.Sep.22 (Fri)

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