c++ coding

Topic 6 Object-oriented Programming (Inheritance) Lecture 6a (chapter 11) CSCI 140: C++ Language & Objects Prof. Dominick Atanasio Book: C++: How to Program 10 ed.

Agenda

 Base classes and derived classes  Relationships between these classes  Constructors and destructors in derived

classes  Member access specifiers: public,

private, and protected.

2

11.1 Introduction  Inheritance  A form of software reuse in which you create a class that absorbs an existing class’s data and behaviors

and enhances them with new capabilities.

 You can designate that a new class should inherit the members of an existing class.  This existing class is called the base class, and the new class is referred to as the derived

class.  A derived class represents a more specialized group of objects.  C++ offers public, protected and private inheritance.  With public inheritance, every object of a derived class is also an object of that derived

class’s base class.  However, base-class objects are not objects of their derived classes.

3

11.1 Introduction (cont.)  We distinguish between the is-a relationship and the has-a relationship.  The is-a relationship represents inheritance.  In an is-a relationship, an object of a derived class also can be treated as an object of its

base class.  By contrast, the has-a relationship represents composition or aggregation.

4

11.2 Base Classes and Derived Classes  Figure 11.1 lists several simple examples of base classes and derived classes.  Base classes tend to be more general and derived classes tend to be more specific.

 Because every derived-class object is an object of its base class, and one base class can have many derived classes, the set of objects represented by a base class typically is larger than the set of objects represented by any of its derived classes.

 Inheritance relationships form class hierarchies.

5

6

11.2.1 CommunityMember Class Hierarchy  Let’s develop a simple inheritance hierarchy with five levels (represented by the UML

class diagram in Fig. 11.2).  A university community has thousands of CommunityMembers.  Employees are either Faculty or Staff.  Faculty are either Administrators or Teachers.  Some Administrators, however, are also Teachers.  We’ve used multiple inheritance to form class AdministratorTeacher.

7

8

11.2.1 CommunityMember Class Hierarchy  With single inheritance, a class is derived from one base class.  With multiple inheritance, a derived class inherits simultaneously from two or more

(possibly unrelated) base classes.

9

11.2.1 CommunityMember Class Hierarchy  Each arrow in the hierarchy (Fig. 11.2) represents an is-a relationship.  As we follow the arrows in this class hierarchy, we can state “an Employee is a CommunityMember”

and “a Teacher is a Faculty member.”  CommunityMember is the direct base class of Employee, Student and Alumnus.  CommunityMember is an indirect base class of all the other classes in the diagram.

 Starting from the bottom of the diagram, you can follow the arrows and apply the is-a relationship to the topmost base class.  An AdministratorTeacher is an Administrator, is a Faculty member, is an Employee and is a

CommunityMember.

10

11.2.2 Shape Class Hierarchy  Consider the Shape inheritance hierarchy in Fig. 11.3.  Begins with base class Shape.  Classes TwoDimensionalShape and ThreeDimensionalShape derive from base class

Shape—Shapes are either TwoDimensionalShapes or Three-DimensionalShapes.  The third level of this hierarchy contains some more specific types of

TwoDimensionalShapes and ThreeDimensionalShapes.  As in Fig. 11.2, we can follow the arrows from the bottom of the diagram to the

topmost base class in this class hierarchy to identify several is-a relationships.

11

12

11.3 Relationship between Base and Derived Classes  In this section, we use an inheritance hierarchy containing types of employees in a

company’s payroll application to discuss the relationship between a base class and a derived class.

 Commission employees (who will be represented as objects of a base class) are paid a percentage of their sales, while base-salaried commission employees (who will be represented as objects of a derived class) receive a base salary plus a percentage of their sales.

13

11.3.1 Creating and Using a CommissionEmployee Class  CommissionEmployee’s class definition (Figs. 11.4–11.5).  CommissionEmployee’s public services include a constructor and member functions

earnings and toString.  Also includes public get and set functions that manipulate the class’s data members

firstName, lastName, socialSecurityNumber, grossSales and commissionRate.  private, so objects of other classes cannot directly access this data.  Declaring data members as private and providing non-private get and set functions to manipulate and

validate the data members helps enforce good software engineering.

14

15

16

17

18

19

20

11.3.1 Creating and Using a CommissionEmployee Class (cont.)

 CommissionEmployee Constructor  The CommissionEmployee constructor definition purposely does not use member-

initializer syntax in the first several examples of this section, so that we can demonstrate how private and protected specifiers affect member access in derived classes.  Later in this section, we’ll return to using member-initializer lists in the constructors.

21

11.3.1 Creating and Using a CommissionEmployee Class (cont.)

 CommissionEmployee Member Functions earnings and toString  Member function earnings calculates a CommissionEmployee’s earnings.  Member function toString displays the values of a CommissionEmployee object’s data

members.  Testing Class CommissionEmployee  Figure 11.6 tests class CommissionEmployee.

22

23

24

25

11.3.2 Creating a BasePlusCommissionEmployee Class Without Using Inheritance

 We now discuss the second part of our introduction to inheritance by creating and testing (a completely new and) independent class BasePlusCommissionEmployee (Figs. 11.7–11.8), which contains a first name, last name, social security number, gross sales amount, commission rate and base salary.

26

27

28

29

30

31

32

33

34

11.3.2 Creating a BasePlusCommissionEmployee Class Without Using Inheritance (cont.)

 Defining Class BasePlusCommissionEmployee  The BasePlusCommissionEmployee header (Fig. 11.7) specifies class

BasePlusCommissionEmployee’s public services, which include the BasePlusCommissionEmployee constructor and member functions earnings and toString.

 Lines 14–30 declare public get and set functions for the class’s private data members firstName, lastName, socialSecurityNumber, grossSales, commissionRate and baseSalary.

35

11.3.2 Creating a BasePlusCommissionEmployee Class Without Using Inheritance (cont.)

 Note the similarity between this class and class Commission-Employee (Figs. 11.4– 11.5)—in this example, we won’t yet exploit that similarity.

 Class BasePlusCommissionEmployee’s earnings member function computes the earnings of a base-salaried commission employee.

 Testing Class BasePlusCommissionEmployee  Figure 11.9 tests class BasePlusCommissionEmployee.

36

11.3.2 Creating a BasePlusCommissionEmployee Class Without Using Inheritance (cont.)

 Exploring the Similarities Between Class BasePlusCommissionEmployee and Class CommissionEmployee

 Most of the code for class BasePlusCommissionEmployee (Figs. 11.7–11.8) is similar, if not identical, to the code for class CommissionEmployee (Figs. 11.4–11.5).

 In class BasePlusCommissionEmployee, private data members firstName and lastName and member functions setFirstName, getFirstName, setLastName and getLastName are identical to those of class CommissionEmployee.

 Both classes contain private data members socialSecurityNumber, commissionRate and grossSales, as well as get and set functions to manipulate these members.

37

11.3.2 Creating a BasePlusCommissionEmployee Class Without Using Inheritance (cont.)

 The BasePlusCommissionEmployee constructor is almost identical to that of class CommissionEmployee, except that BasePlusCommissionEmployee’s constructor also sets the baseSalary.

 The other additions to class BasePlusCommissionEmployee are private data member baseSalary and member functions setBaseSalary and getBaseSalary.

 Class BasePlusCommissionEmployee’s toString member function is nearly identical to that of class CommissionEmployee, except that BasePlusCommissionEmployee’s toString also outputs the value of data member baseSalary.

38

11.3.2 Creating a BasePlusCommissionEmployee Class Without Using Inheritance (cont.)

 We literally copied code from class CommissionEmployee and pasted it into class BasePlusCommissionEmployee, then modified class BasePlusCommissionEmployee to include a base salary and member functions that manipulate the base salary.

 This copy-and-paste approach is error prone and time consuming.  Worse yet, it can spread many physical copies of the same code throughout a system,

creating a code-maintenance nightmare.

39

40

41

11.3.3 Creating a CommissionEmployee–BasePlusCommissionEmployee Inheritance Hierarchy

 Now we create and test a new BasePlusCommissionEmployee class (Figs. 11.10–11.11) that derives from CommissionEmployee (Figs. 11.4–11.5).

 In this example, a BasePlusCommissionEmployee object is a CommissionEmployee (because inheritance passes on the capabilities of class CommissionEmployee), but class BasePlusCommissionEmployee also has data member baseSalary (Fig. 11.10, line 21).

 The colon (:) in line 10 of the class definition indicates inheritance.  Keyword public indicates the type of inheritance.  As a derived class (formed with public inheritance), BasePlusCommissionEmployee

inherits all the members of class CommissionEmployee, except for the constructor— each class provides its own constructors that are specific to the class.

42

11.3.3 Creating a CommissionEmployee–BasePlusCommissionEmployee Inheritance Hierarchy (cont.)

 Destructors, too, are not inherited  Thus, the public services of BasePlusCommissionEmployee include its constructor and

the public member functions inherited from class CommissionEmployee—although we cannot see these inherited member functions in BasePlusCommissionEmployee’s source code, they’re nevertheless a part of derived class BasePlusCommissionEmployee.

 The derived class’s public services also include member functions setBaseSalary, getBaseSalary, earnings and toString.

43

44

45

46

47

11.3.3 Creating a CommissionEmployee–BasePlusCommissionEmployee Inheritance Hierarchy (cont.)

 Figure 11.11 shows BasePlusCommissionEmployee’s member-function implementations.

 The constructor introduces base-class initializer syntax, which uses a member initializer to pass arguments to the base-class constructor.

 C++ requires that a derived-class constructor call its base-class constructor to initialize the base-class data members that are inherited into the derived class.

 If BasePlusCommissionEmployee’s constructor did not invoke class CommissionEmployee’s constructor explicitly, C++ would attempt to invoke class CommissionEmployee’s default constructor—but the class does not have such a constructor, so the compiler would issue an error.

48

49

50

11.3.3 Creating a CommissionEmployee–BasePlusCommissionEmployee Inheritance Hierarchy (cont.)

 Compilation Errors from Accessing Base-Class private Members  The compiler generates errors for line 35 of Fig. 11.11 because base class

CommissionEmployee’s data members commissionRate and grossSales are private— derived class BasePlusCommissionEmployee’s member functions are not allowed to access base class CommissionEmployee’s private data.

 We used red text in Fig. 11.11 to indicate erroneous code.  The compiler issues additional errors in lines 44–47 of BasePlus-Commission-

Employee’s toString member function for the same reason.  C++ rigidly enforces restrictions on accessing private data members, so that even a

derived class (which is intimately related to its base class) cannot access the base class’s private data.

51

11.3.3 Creating a CommissionEmployee–BasePlusCommissionEmployee Inheritance Hierarchy (cont.)

 Preventing the Errors in BasePlusCommissionEmployee  We purposely included the erroneous code in Fig. 11.11 to emphasize that a derived

class’s member functions cannot access its base class’s private data.  The errors in BasePlusCommissionEmployee could have been prevented by using the

get member functions inherited from class CommissionEmployee.

52

11.3.3 Creating a CommissionEmployee–BasePlusCommissionEmployee Inheritance Hierarchy (cont.)

 For example, line 37 could have invoked getCommissionRate and getGrossSales to access CommissionEmployee’s private data members commissionRate and grossSales, respectively.

 Similarly, lines 44–47 could have used appropriate get member functions to retrieve the values of the base class’s data members.

53

11.3.3 Creating a CommissionEmployee–BasePlusCommissionEmployee Inheritance Hierarchy (cont.)

 Including the Base-Class Header in the Derived-Class Header with #include  We #include the base class’s header in the derived class’s header (line 8 of Fig. 11.10).  This is necessary for three reasons.  The derived class uses the base class’s name, so we must tell the compiler that the base class exists.  The compiler uses a class definition to determine the size of an object of that class. A client program

that creates an object of a class #includes the class definition to enable the compiler to reserve the proper amount of memory.

 The compiler must determine whether the derived class uses the base class’s inherited members properly.

54

11.3.3 Creating a CommissionEmployee–BasePlusCommissionEmployee Inheritance Hierarchy (cont.)

 Linking Process in an Inheritance Hierarchy  In Section 9.3, we discussed the linking process for creating an executable Time

application.  The linking process is similar for a program that uses classes in an inheritance hierarchy.  The process requires the object code for all classes used in the program and the object

code for the direct and indirect base classes of any derived classes used by the program.

 The code is also linked with the object code for any C++ Standard Library classes used.

55

11.3.4 CommissionEmployee–BasePlusCommissionEmployee Inheritance Hierarchy Using protected Data

 In this section, we introduce the access specifier protected.  To enable class BasePlusCommissionEmployee to directly access CommissionEmployee

data members firstName, lastName, socialSecurityNumber, grossSales and commissionRate, we can declare those members as protected in the base class.

 A base class’s protected members can be accessed within the body of that base class, by members and friends of that base class, and by members and friends of any classes derived from that base class.

56

11.3.4 CommissionEmployee–BasePlusCommissionEmployee Inheritance Hierarchy Using protected Data (cont.)

 Defining Base Class CommissionEmployee with protected Data  Class CommissionEmployee (Fig. 11.12) now declares data members firstName,

lastName, socialSecurityNumber, grossSales and commissionRate as protected (lines 30–35) rather than private.

 The member-function implementations are identical to those in Fig. 11.5.

57

58

59

11.3.4 CommissionEmployee–BasePlusCommissionEmployee Inheritance Hierarchy Using protected Data (cont.)

 BasePlusCommissionEmployee inherits from class CommissionEmployee in Fig. 11.12.  Objects of class BasePlusCommissionEmployee can access inherited data members that

are declared protected in class CommissionEmployee (i.e., data members firstName, lastName, socialSecurityNumber, grossSales and commissionRate).

 As a result, the compiler does not generate errors when compiling the BasePlusCommissionEmployee earnings and toString member-function definitions in Fig. 11.11 (lines 34–38 and 41–49, respectively).

 Objects of a derived class also can access protected members in any of that derived class’s indirect base classes.

60

11.3.4 CommissionEmployee–BasePlusCommissionEmployee Inheritance Hierarchy Using protected Data (cont.)

 Notes on Using protected Data  Inheriting protected data members slightly increases performance, because we can

directly access the members without incurring the overhead of calls to set or get member functions.

61

62

11.3.4 CommissionEmployee–BasePlusCommissionEmployee Inheritance Hierarchy Using protected Data (cont.)

 Using protected data members creates two serious problems.  The derived-class object does not have to use a member function to set the value of the base class’s

protected data member.  Derived-class member functions are more likely to be written so that they depend on the base-class

implementation. Derived classes should depend only on the base-class services (i.e., non-private member functions) and not on the base-class implementation.

 With protected data members in the base class, if the base-class implementation changes, we may need to modify all derived classes of that base class.

 Such software is said to be fragile or brittle, because a small change in the base class can “break” derived-class implementation.

63

64

65

11.3.5 CommissionEmployee–BasePlusCommissionEmployee Inheritance Hierarchy Using private Data

 We now reexamine our hierarchy once more, this time using the best software engineering practices.

 Class CommissionEmployee now declares data members firstName, lastName, socialSecurityNumber, grossSales and commissionRate as private (as shown previously in lines 31–35 of Fig. 11.4).

66

11.3.5 CommissionEmployee–BasePlusCommissionEmployee Inheritance Hierarchy Using private Data (cont.)

 Changes to Class CommissionEmployee’s Member Function Definitions  In the CommissionEmployee constructor implementation (Fig. 11.14, lines 10–15), we

use member initializers (line 12) to set the values of members firstName, lastName and socialSecurityNumber.

 Though we do not do so here, derived-class BasePlusCommissionEmployee (Fig. 11.15) can invoke non-private base-class member functions (setFirstName, getFirstName, setLastName, getLastName, setSocialSecurityNumber and getSocialSecurityNumber) to manipulate these data members, , as can any client code of class BasePlusCommissionEmployee (such as main).

67

68

69

70

71

72

73

11.3.5 CommissionEmployee–BasePlusCommissionEmployee Inheritance Hierarchy Using private Data (cont.)

 Changes to Class BasePlusCommissionEmployee’s Member Function Definitions  Class BasePlusCommissionEmployee has several changes to its member-function

implementations (Fig. 11.15) that distinguish it from the previous version of the class (Figs. 11.10–11.11).

 Member functions earnings (Fig. 11.15, lines 32–34) and toString (lines 37–42) each invoke getBaseSalary to obtain the base salary value.

74

75

76

77

11.3.5 CommissionEmployee–BasePlusCommissionEmployee Inheritance Hierarchy Using private Data (cont.)

 BasePlusCommissionEmployee Member Function earnings  Class BasePlusCommissionEmployee’s earnings function (Fig. 11.15, lines 32–34)

redefines class CommissionEmployee’s earnings member function (Fig. 11.14, lines 70– 72) to calculate the earnings of a base-salaried commission employee. It also calls CommissionEmployee’s earnings function.  Note the syntax used to invoke a redefined base-class member function from a derived class—place

the base-class name and the binary scope resolution operator (::) before the base-class member- function name.

 Good software engineering practice: If an object’s member function performs the actions needed by another object, we should call that member function rather than duplicating its code body.

78

79

11.3.5 CommissionEmployee–BasePlusCommissionEmployee Inheritance Hierarchy Using private Data (cont.)

 BasePlusCommissionEmployee Member Function toString  BasePlusCommissionEmployee’s toString function (Fig. 11.15, lines 37–42) redefines

class CommissionEmployee’s toString function (Fig. 11.14, lines 75–84) to output the appropriate base-salaried commission employee information.

 By using inheritance and by calling member functions that hide the data and ensure consistency, we’ve efficiently and effectively constructed a well-engineered class.

80

11.4 Constructors and Destructors in Derived Classes  Instantiating a derived-class object begins a chain of constructor calls in which the

derived-class constructor, before performing its own tasks, invokes its direct base class’s constructor either explicitly (via a base-class member initializer) or implicitly (calling the base class’s default constructor).

 If the base class is derived from another class, the base-class constructor is required to invoke the constructor of the next class up in the hierarchy, and so on.

 The last constructor called in this chain is the constructor of the class at the base of the hierarchy, whose body actually finishes executing first.

 The most derived-class constructor’s body finishes executing last.  Each base-class constructor initializes the base-class data members that the derived-

class object inherits.

81

82

11.4 Constructors and Destructors in Derived Classes (cont.)  When a derived-class object is destroyed, the program calls that object’s destructor.  This begins a chain (or cascade) of destructor calls in which the derived-class destructor

and the destructors of the direct and indirect base classes and the classes’ members execute in reverse of the order in which the constructors executed.

 When a derived-class object’s destructor is called, the destructor performs its task, then invokes the destructor of the next base class up the hierarchy.

 This process repeats until the destructor of the final base class at the top of the hierarchy is called.

 Then the object is removed from memory.

83

84

11.4 Constructors and Destructors in Derived Classes (cont.)  Base-class constructors, destructors and overloaded assignment operators (Chapter 10)

are not inherited by derived classes.  Derived-class constructors, destructors and overloaded assignment operators, however,

can call base-class versions.

85

11.4 Constructors and Destructors in Derived Classes (cont.)  C++11: Inheriting Base Class Constructors  Sometimes a derived class’s constructors simply specify the same parameters as the

base class’s constructors.  For such cases, C++11 allows you to specify that a derived class should inherit a base

class’s constructors.  To do this explicitly include a using declaration of the following form anywhere in the

derived-class definition:  using BaseClass::BaseClass;

 In the preceding declaration, BaseClass is the base class’s name.

86

11.4 Constructors and Destructors in Derived Classes (cont.)  When you inherit constructors:  Each inherited constructor has the same access specifier (public, protected or private) as its

corresponding base-class constructor.  The default, copy and move constructors are not inherited.  If a constructor is deleted in the base class by placing = delete in its prototype, the corresponding

constructor in the derived class is also deleted.  If the derived class does not explicitly define constructors, the compiler still generates a default

constructor in the derived class.  A given base-class constructor is not inherited if a constructor that you explicitly define in the derived

class has the same parameter list.  A base-class constructor’s default arguments are not inherited. Instead, the compiler generates

overloaded constructors in the derived class.

87

11.5 public, protected and private Inheritance  When deriving a class from a base class, the base class may be inherited through

public, protected or private inheritance.  Use of protected and private inheritance is rare.  Figure 11.16 summarizes for each type of inheritance the accessibility of base-class

members in a derived class.  The first column contains the base-class access specifiers.  A base class’s private members are never accessible directly from a derived class, but

can be accessed through calls to the public and protected members of the base class.

88

89