home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs
lab05a
fields
PizzaServer, tips, and managers
Work through today's lab with a partner.
(You are encouraged to be brave,
and work with somebody you haven't worked with before.)
Starting with the changes made last week to
paste it into BlueJ, as your starting point.
-
Review lect05a—Introduction to objects: fields: PizzaServer salary,
for the syntax of
-
declaring a field,
-
writing a getter method,
-
writing a setter method.
-
Copy/paste
PizzaServer.java
(or, modify your previous version)
with the version we saw in Lecture:
a field salary,
along with the “getter” method
getSalary,
and the “setter” method
setSalary.
-
Using BlueJ's pop-up menus:
create two PizzaServer instances
(creating them with the menu item new PizzaServer()),
and then (when BlueJ prompts you) give the name
of local variables to refer to these new servers.
-
Right-click on the red objects, and choose Inspect.
-
Call the getSalary on one of them to confirm they make
minimum wage,
and then set one of their salaries to something different.
Confirm that the salary of that PizzaServer changes,
while the other salary is unchanged.
-
What is a java expression which corresponds to the sum of the
salaries of the two PizzaServers you created above?
Type it in, in the Code Pad.
(All this so far, we've already seen in lecture (some recent, some old).)
-
We decide that in addition to the salary, there's a second piece
of information which is specific to each PizzaServer:
their bank-account-balance.
-
Make a field balance.
To think about: What do you want to declare as
the initial-value of a new PizzaServer's bank balance?
- Write a getter method.
- Write a setter method.
- Run a few interactive tests,
to make sure your new methods work:
-
Make two PizzaServers;
-
verify their initial balance is what it should be;
-
for one of the PizzaServer,
set the their balance to some value;
-
verify that getBalance returns this new value,
and that the balance of the other PizzaServer
has not changed.
-
Add a behavior void tip(double amt),
which represents giving somebody a direct under-the-table tip which goes
straight into the server's balance.
Note that no value should be returned from this function1.
Note that you should use
this.getBalance() and this.setBalance(double),
but not refer to the fields this.salary
or this.balance directly.
Principle: Only the getters and setters will refer to the field directly.
-
Add a behavior void work(double hrs), which
takes a number of hours worked and changes
the PizzaServer's
balance by the appropriate amount.
Record a test method (which calls work at least twice,
interspersed with calls to getBalance to confirm it worked.).
We won't check off this lab (due to the exam),
but we will build on it next week;
you'll be expected to have completed and understood the above tasks!
-
Do you have repeated code in the above two methods?
Factor out the common code by adding a method addToBalance;
then go back and modify tip and work
so that they call addToBalance.
You'll want to record some new tests for addToBalance by itself,
but you won't have to re-record any tests for tip
or work, since you already recorded test cases for that.
(Of course, you should re-run those tests, to confirm the functions still work.)
-
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.)
Extend your previous test function with some tests for this.
-
Revise setSalary so that it's consistent with federal law:
you can't set the salary to be lower than the minimum wage.
If setSalary is called with a lower value,
then the salary is set to the minimum.
Observe that even if setSalary was called by other functions
(say, “demote”), we now get compliance
with federal law, by simply making a change in one place.
If other places in the code had not used the setter,
then we would have to make a bunch of changes to comply with law.
-
Now we have an ugliness though:
The constant 5.75 occurs twice in our program.
Make it a named constant.
What good are named constants, again?
Well, there might be other parts of code which need to refer to the minimum wage,
for other reasons.
And if the minimum wage changes, then we'll have to pore over2 our entire program, deciding
which versions of 5.75 need to be updated, and which 5.75's aren't referring
to a wage (perhaps, it's also coincidentally the price of tea in China).
As a named constant,
(not local to any particular field),
the constant can be used in multiple places:
both when initializing the salary,
and when running setSalary.
-
In addition to a salary and balance, suppose that PizzaServers
also one further piece of information:
whether or not they are a manager.
Add a field isManager to the class, along with methods
getIsManager and setIsManager.
Check that your method works. (How?)
1
If you really want, you can program PizzaServers
to be polite and always return "Thank you!" when tipped. ↩
2Yep,
“to read extremely closely” is “pore over”,
not “pour over”. ↩
home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs
rad�ford.edu