Java Reference
In-Depth Information
only methods may have a return type. Non- void return types allow us to pass a value out of
a method to the place where the method was called from. A method with a non- void return
type must have at least one return statement in its body; this will often be the final statement.
Constructors never have a return type of any sort—not even void .
Before attempting these exercises, be sure that you have a good understanding of how ticket
machines behave and how that behavior is implemented through the fields, constructor, and
methods of the class.
Exercise 2.43 Modify the constructor of TicketMachine so that it no longer has a pa-
rameter. Instead, the price of tickets should be fixed at 1,000 cents. What effect does this have
when you construct ticket-machine objects within BlueJ?
Exercise 2.44 Give the class two constructors. One should take a single parameter that speci-
fies the price, and the other should take no parameter and set the price to be a default value of
your choosing. Test your implementation by creating machines via the two different constructors.
Exercise 2.45 Implement a method, empty , that simulates the effect of removing all money
from the machine. This method should have a void return type, and its body should simply
set the total field to zero. Does this method need to take any parameters? Test your method
by creating a machine, inserting some money, printing some tickets, checking the total, and
then emptying the machine. Is the empty method a mutator or an accessor?
Reflecting on the design of the ticket machine
From our study of the internals of the TicketMachine class, you should have come to ap-
preciate how inadequate it would be in the real world. It is deficient in several ways:
It contains no check that the customer has entered enough money to pay for a ticket.
It does not refund any money if the customer pays too much for a ticket.
It does not check to ensure that the customer inserts sensible amounts of money: experiment
with what happens if a negative amount is entered, for instance.
It does not check that the ticket price passed to its constructor is sensible.
If we could remedy these problems, then we would have a much more functional piece of soft-
ware that might serve as the basis for operating a real-world ticket machine.
In the next few sections, we shall examine the implementation of an improved ticket machine class
that attempts to deal with some of the inadequacies of the naïve implementation. Open the better-
ticket-machine project. As before, this project contains a single class: TicketMachine . Before
looking at the internal details of the class, experiment with it by creating some instances and see
whether you notice any differences in behavior between this version and the previous naïve version.
One specific difference is that the new version has an additional method, refundBalance .
Take a look at what happens when you call it.
Search WWH ::

Custom Search