concept Employee in category java

This is an excerpt from Manning's book OCA Java SE 8 Programmer I Certification Guide. Login to get full access to this book.

Explanation: The rules you need to follow to assign a value to an array element are the same rules you follow when you assign an object to a reference variable. Because the type of array interviewer is Interviewer, you can assign objects of classes that implement this interface. The inheritance of classes Employee, Manager, and HRExecutive and the interface Interviewer are shown in figure A.5.

Figure A.5. UML notation of inheritance hierarchy of the classes Employee, Manager, and HRExecutive and the interface Interviewer

As you can see in figure A.5, the classes Manager and HRExecutive implement the interface Interviewer. The class Employee doesn’t implement the interface Interviewer; hence, an object of the class Employee can’t be added to an array of type Interviewer.

Did you notice that the classes Programmer and Manager have common properties, namely, name, address, phoneNumber, and experience? The next step is to pull out these common properties into a new position and name it something like Employee. This step is shown in figure 6.2.

Figure 6.2. Identify common properties and behaviors of a Programmer and a Manager, pull them out into a new position, and name it Employee.

This new position, Employee, can be defined as a new class, Employee, which is inherited by the classes Programmer and Manager. A class uses the keyword extends to inherit a class, as shown in figure 6.3.

Figure 6.3. The classes Programmer and Manager extend the class Employee.

Inheriting a class is also referred to as subclassing. In figure 6.3, the inherited class Employee is also referred to as the superclass, base class, or parent class. The classes Programmer and Manager that inherit the class Employee are called subclasses, derived classes, extended classes, or child classes.

Why do you think you need to pull out the common properties and behaviors into a separate class Employee and make the Programmer and Manager classes inherit it? The next section covers the benefits of inheriting classes.

Let’s consider polymorphism using the classes Employee, Programmer, and Manager, where the classes Programmer and Manager inherit the class Employee. Figure 6.27 shows a UML diagram depicting the relationships among these classes.

Figure 6.27. Relationships among the classes Employee, Programmer, and Manager

We’ll start with the Employee class, which is not quite sure about what must be done to start work on a project (execute method startProjectWork). Hence, the method startProjectWork is defined as an abstract method, and the class Employee is defined as an abstract class, as follows:

The class Programmer extends the class Employee, which essentially means that it has access to the method reachOffice defined in Employee. Programmer must also implement the abstract method startProjectWork, inherited from Employee. How do you think a Programmer will typically start work on a programming project? Most probably, the Programmer will define classes and unit test them. This behavior is contained in the definition of the class Programmer, which implements the method start-ProjectWork, as follows:

class Programmer extends Employee {
    public void startProjectWork() {
        defineClasses();
        unitTestCode();
    }
    private void defineClasses() { System.out.println("define classes"); }
    private void unitTestCode() { System.out.println("unit test code"); }
}

copy

We’re fortunate to have another special type of Employee, a Manager, who knows how to start work on a project. How do you think a Manager will typically start work on a programming project? Most probably, the Manager will meet with the customers, define a project schedule, and assign work to the team members. Here’s the definition of the class Manager that extends the class Employee and implements the method startProjectWork: