Problem

(Accounts Payable System Modification) It's possible to include the functionality of t...

(Accounts Payable System Modification) It's possible to include the functionality of the payroll application (Figs. 25—30) in the accounts payable application without modifying Employee subclasses SalariedEmployee, HourlyEmployee, CommissionEmployee or BasePlusCommissionEmployee. To do so, you can modify class Employee (Fig. 25) to implement interface Payabl e and declare method getPaymentAmount to invoke method earnings. Method getPaymentAmount would then be inherited by the subclasses in the Empl oyee hierarchy. When getPaymentAmount is called for a particular subclass object, it polymorphically invokes the appropriate earnings method for that subclass. Reimplement Exercise using the original Employee hierarchy from the payroll application of Figs. 25—30. Modify class Employee as described in this exercise, and do not modify any of class Employee's subclasses.

Fig. 25 Employee abstract superclass.

Fig. 26 SalariedEmployee concrete class extends abstract class Employee.

Fig. 27 HourlyEmployee class extends Employee.

Fig. 28 CommissionEmployee class extends Employee.

Fig. 29 BasePlusCommissionEmployee class extends CommissionEmployee.

Fig. 30 Employee hierarchy test program.

Exercise

(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. 14—19. 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. Complete the following steps to create the new application:

a) Modify classes HourlyEmployee (Fig. 20) and CommissionEmployee (Fig. 21) to place them in the Payable hierarchy as subclasses of the version of Employee (Fig. 22) 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.]
Fig. 14 Employee abstract superclass.
Fig. 15 SalariedEmployee concrete class extends abstract class Employee.
Fig. 16 HourlyEmployee class extends Employee.
Fig. 17 CommissionEmployee class extends Employee.
Fig. 18 BasePlusCommissionEmployee class extends CommissionEmployee.
Fig. 19 Employee hierarchy test program.
Fig. 20 | HourlyEmployee class extends Employee.
Fig. 21 | CommissionEmployee class extends Employee.
Fig. 22 Employee abstract superclass that implements Payable.
b) Modify class BasePlusCommissionEmployee (Fig. 23) such that it extends the version of class Commi ssionEmployee created in part (a).
Fig. 23 | BasePlusCommissionEmployee class extends CommissionEmployee
c) Modify PayableInterfaceTest (Fig. 24) to polymorphically process two Invoices, one SalariedEmployee, one HourlyEmployee, one CommissionEmployee and one Base-Pl usCommissionEmployee. First output a String representation of each Payable object. Next, if an object is a BasePlusCommissionEmployee, increase its base salary by 10%. Finally, output the payment amount for each Payable object.