Java Reference
In-Depth Information
10.15
(Accounts Payable System Modification)
In this exercise, we modify the accounts payable
application of Figs. 10.11-10.15 to include the complete functionality of the payroll application of
Figs. 10.4-10.9. The application should still process two
Invoice
objects, but now should process
one object of each of the four
Employee
subclasses. If the object currently being processed is a
Base-
PlusCommissionEmployee
, the application should increase the
BasePlusCommissionEmployee
's base
salary by 10%. Finally, the application should output the payment amount for each object. Com-
plete the following steps to create the new application:
a) Modify classes
HourlyEmployee
(Fig. 10.6) and
CommissionEmployee
(Fig. 10.7) to place
them in the
Payable
hierarchy as subclasses of the version of
Employee
(Fig. 10.13) that
implements
Payable
. [
Hint:
Change the name of method
earnings
to
getPaymentAmount
in each subclass so that the class satisfies its inherited contract with interface
Payable
.]
b) Modify class
BasePlusCommissionEmployee
(Fig. 10.8) such that it extends the version
of class
CommissionEmployee
created in part (a).
c) Modify
PayableInterfaceTest
(Fig. 10.15) to polymorphically process two
Invoice
s,
one
SalariedEmployee
, one
HourlyEmployee
, one
CommissionEmployee
and one
Base-
PlusCommissionEmployee
. First output a
String
representation of each
Payable
object.
Next, if an object is a
BasePlusCommissionEmployee
, increase its base salary by 10%. Fi-
nally, output the payment amount for each
Payable
object.
10.16
(Accounts Payable System Modification)
It's possible to include the functionality of the pay-
roll application (Figs. 10.4-10.9) in the accounts payable application without modifying
Employee
subclasses
SalariedEmployee
,
HourlyEmployee
,
CommissionEmployee
or
BasePlusCommission-
Employee
. To do so, you can modify class
Employee
(Fig. 10.4) to implement interface
Payable
and
declare method
getPaymentAmount
to invoke method
earnings
. Method
getPaymentAmount
would
then be inherited by the subclasses in the
Employee
hierarchy. When
getPaymentAmount
is called for
a particular subclass object, it polymorphically invokes the appropriate
earnings
method for that
subclass. Reimplement Exercise 10.15 using the original
Employee
hierarchy from the payroll appli-
cation of Figs. 10.4-10.9. Modify class
Employee
as described in this exercise, and
do not
modify any
of class
Employee
's subclasses.
Making a Difference
10.17
(
CarbonFootprint
Interface: Polymorphism)
Using interfaces, as you learned in this chap-
ter, you can specify similar behaviors for possibly disparate classes. Governments and companies
worldwide are becoming increasingly concerned with carbon footprints (annual releases of carbon
dioxide into the atmosphere) from buildings burning various types of fuels for heat, vehicles burning
fuels for power, and the like. Many scientists blame these greenhouse gases for the phenomenon
called global warming. Create three small classes unrelated by inheritance—classes
Building
,
Car
and
Bicycle
. Give each class some unique appropriate attributes and behaviors that it does not have
in common with other classes. Write an interface
CarbonFootprint
with a
getCarbonFootprint
method. Have each of your classes implement that interface, so that its
getCarbonFootprint
method
calculates an appropriate carbon footprint for that class (check out a few websites that explain how
to calculate carbon footprints). Write an application that creates objects of each of the three classes,
places references to those objects in
ArrayList<CarbonFootprint>
, then iterates through the
Array-
List
, polymorphically invoking each object's
getCarbonFootprint
method. For each object, print
some identifying information and the object's carbon footprint.
