BBj Custom Objects Tutorial: Program #5 - Class Inheritance

Example Programs

Here are some example BBj programs. Each example is designed to demonstrate some aspect of using Custom Object Classes in BBj.

The complete source code for each program is included in an appropriately named sub-folder in the zip file you can download here.

Program #5: Class Inheritance

Let’s take a look at a BBj program that demonstrates how to use class inheritance to pay employees when there are multiple types of employees. We will create a simple Employee class to hold the attributes and operations that are common to all types of employees. Then we will extend the Employee class to create two subclasses, SalariedEmployee and CommissionedEmployee. It should be intuitive that the logic to pay employees of the different types will have to be different for each type. In this example, we create a PayMaster class to hold the logic for paying all of our employees. PayMaster in turn relies on information from the various Employee classes, together with its own “pay by writing a check” logic. For simplicity, we will use the same Check and PayrollCheck classes from Program 3 to help make the payments. Again, we show the code for each new source file using a different border color for readability:

Program 5. The Classes and Other Code to Pay Employees

Execution

Creating the BBj source files and then running Program 5 (the code in PayEmployees.bbj) resulted in the following SysConsole output:

Figure 5. The Output from Program 5

Observations

Here are some details that this code demonstrates:

  • Only the code in PayEmployees.bbj explicitly uses the SalariedEmployee and CommissionedEmployee subclasses. All other access uses a reference to the Employee superclass. This means if, in the future, you add more subclasses than just those two, the various classes will continue to work. The exception is the code in PayEmployees.bbj, of course. That code is specifically interested in working with salaried vs. commissioned employees, and presumably is where any new subclasses would be needed.

  • The PayMaster.pay(Employee employeeToPay!) method is an example of object-oriented programming that relies upon classes and inheritance to work. It takes as an argument a reference to a superclass, when in reality the code will always pass an instance of one of its subclasses. As an alternative, you could have created two PayMaster.pay() methods, one for each of the subclasses we created. This, however, would mean that every time you add a new subclass, you would need to add another method to the PayMaster class.

  • You could easily enhance the PayMaster class by giving its constructor a parameter to take in the tax rate (instead of having the TaxRate field fixed at 0.30). Since the PayMaster class consistently uses the TaxRate field instead of the literal “0.30” value, this would be a simple improvement, and the class would be more generally useful.

  • The EmployeeIF Interface is not absolutely necessary in this simple case, but it demonstrates how you can share an interface definition without sharing any implementation details. This sharing is useful in object-oriented programming to help avoid coupling between class implementations.

Next Step: Example Program #6

BBj Custom Objects Tutorial Contents

BBj Custom Objects Tutorial: Introduction

BBj Custom Objects Tutorial: Interfaces

BBj Custom Objects Tutorial: Classes

BBj Custom Objects Tutorial: Fields

BBj Custom Objects Tutorial: Methods

BBj Custom Objects Tutorial: Using Custom Objects

BBj Custom Objects Tutorial: Program #1 - Writing a Check

BBj Custom Objects Tutorial: Program #2 - Protected and Private Fields

BBj Custom Objects Tutorial: Program #3: The Static Keyword

BBj Custom Objects Tutorial: Program #4 - Error Handling

BBj Custom Objects Tutorial: Program #5 - Class Inheritance

BBj Custom Objects Tutorial: Program #6 - Callback Choices

BBj Custom Objects Tutorial: Program #7 - Constructors and Field Initialization