With polymorphism, we can design and implement systems that are easily extensible—new classes can be added with little or no modification to the general portions of the application, as long as the new classes are part of the inheritance hierarchy that the application processes generically. The only parts of an application that must be altered to accommodate new classes are those that require direct knowledge of the new classes that you add to the hierarchy. For example, if we extend class Animal to create class Tortoise (which might respond to a Move message by crawling one inch), we need to write only the Tortoise class and the part of the simulation that instantiates a Tortoise object. The portions of the simulation that process each Animal generically can remain the same.

This chapter has several parts. First, we discuss common examples of polymorphism. We then provide a live-code example demonstrating polymorphic behavior. As you’ll soon see, you’ll use base-class references to manipulate both base-class objects and derived-class objects polymorphically.

We then present a case study that revisits the employee hierarchy of Section 11.4.5. We develop a simple payroll application that polymorphically calculates the weekly pay of several different types of employees using each employee’s Earnings method. Though the earnings of each type of employee are calculated in a specific way, polymorphism allows us to process the employees “in the general.” In the case study, we enlarge the hierarchy to include two new classes—SalariedEmployee (for people paid a fixed weekly salary) and HourlyEmployee (for people paid an hourly salary and “time-and-a-half” for overtime). We declare a common set of functionality for all the classes in the updated hierarchy in an “abstract” class, Employee, from which classes SalariedEmployee, HourlyEmployee and CommissionEmployee inherit directly and class BasePlusCommissionEmployee inherits indirectly. As you’ll soon see, when we invoke each employee’s Earnings method off a baseclass Employee reference, the correct earnings calculation is performed due to C#’s polymorphic capabilities.

Occasionally, when performing polymorphic processing, we need to program “in the specific.” Our Employee case study demonstrates that an application can determine the type of an object at execution time and act on that object accordingly. In the case study, we use these capabilities to determine whether a particular employee object is a BasePlusCommissionEmployee. If so, we increase that employee’s base salary by 10%.

The chapter continues with an introduction to C# interfaces. An interface describes a set of methods and properties that can be called on an object, but does not provide concrete implementations for them. You can declare classes that implement (i.e., provide concrete implementations for the methods and properties of) one or more interfaces. Each interface member must be defined for all the classes that implement the interface. Once a class implements an interface, all objects of that class have an is-a relationship with the interface type, and all objects of the class are guaranteed to provide the functionality described by the interface. This is true of all derived classes of that class as well.

Interfaces are particularly useful for assigning common functionality to possibly unrelated classes. This allows objects of unrelated classes to be processed polymorphically—objects of classes that implement the same interface can respond to the same method calls. To demonstrate creating and using interfaces, we modify our payroll application to create a general accounts-payable application that can calculate payments due for the earnings of company employees and for invoice amounts to be billed for purchased goods. As you’ll see, interfaces enable polymorphic capabilities similar to those enabled by inheritance.

This chapter ends with an introduction to operator overloading. In previous chapters, we declared our own classes and used methods to perform tasks on objects of those classes. Operator overloading allows us to define the behavior of the built-in operators, such as +, - and <, when used on objects of our own classes. This provides a much more convenient notation than calling methods for performing tasks on objects.

If class Rectangle is derived from class Quadrilateral (a four-sided shape), then a Rectangle is a more specific version of a Quadrilateral. Any operation (e.g., calculating the perimeter or the area) that can be performed on a Quadrilateral object can also be performed on a Rectangle object. These operations also can be performed on other Quadrilaterals, such as Squares, Parallelograms and Trapezoids. The polymorphism occurs when an application invokes a method through a base-class variable—at execution time, the correct derived-class version of the method is called, based on the type of the referenced object. You’ll see a simple code example that illustrates this process in Section 12.3.

As another example, suppose we design a video game that manipulates objects of many different types, including objects of classes Martian, Venusian, Plutonian, SpaceShip and LaserBeam. Imagine that each class inherits from the common base class SpaceObject, which contains method Draw. Each derived class implements this method. A screen-manager application maintains a collection (e.g., a SpaceObject array) of references to objects of the various classes. To refresh the screen, the screen manager periodically sends each object the same message—namely, Draw. However, each object responds in a unique way. For example, a Martian object might draw itself in red with the appropriate number of antennae. A SpaceShip object might draw itself as a bright silver flying saucer. A LaserBeam object might draw itself as a bright red beam across the screen. Again, the same message (in this case, Draw) sent to a variety of objects has many forms of results.

A polymorphic screen manager might use polymorphism to facilitate adding new classes to a system with minimal modifications to the system’s code. Suppose we want to add Mercurian objects to our video game. To do so, we must build a Mercurian class that extends SpaceObject and provides its own Draw method implementation. When objects of class Mercurian appear in the SpaceObject collection, the screen-manager code invokes method Draw, exactly as it does for every other object in the collection, regardless of its type, so the new Mercurian objects simply “plug right in” without any modification of the screen-manager code by the programmer. Thus, without modifying the system (other than to build new classes and modify the code that creates new objects), you can use polymorphism to include additional types that might not have been envisioned when the system was created.

Software Engineering Observation 12.1

Polymorphism promotes extensibility: Software that invokes polymorphic behavior is independent of the object types to which messages are sent. New object types that can respond to existing method calls can be incorporated into a system without requiring modification of the base system. Only client code that instantiates new objects must be modified to accommodate new types.

Polymorphism is particularly effective for implementing so-called layered software systems. In operating systems, for example, each type of physical device could operate quite differently from the others. Even so, common commands can read or write data from and to the devices. For each device, the operating system uses a piece of software called a device driver to control all communication between the system and the device. The write message sent to a device driver object needs to be interpreted specifically in the context of that driver and how it manipulates a specific device. However, the write call itself really is no different from the write to any other device in the system: Place some number of bytes from memory onto that device. An object-oriented operating system might use an abstract base class to provide an “interface” appropriate for all device drivers. Then, through inheritance from that abstract base class, derived classes are formed that all behave similarly. The device-driver methods are declared as abstract methods in the abstract base class. The implementations of these abstract methods are provided in the derived classes that correspond to the specific types of device drivers. New devices are always being developed, often long after the operating system has been released. When you buy a new device, it comes with a device driver provided by the device vendor. The device is immediately operational after you connect it to your computer and install the device driver. This is another elegant example of how polymorphism makes systems extensible.

It’s common in object-oriented programming to declare an iterator class that can traverse all the objects in a collection, such as an array (Chapter 8) or a List (Chapter 9). For example, an application can print a List of objects by creating an iterator object and using it to obtain the next list element each time the iterator is called. Iterators often are used in polymorphic programming to traverse a collection that contains references to objects of various classes in an inheritance hierarchy. (Chapters 22–23 present a thorough treatment of C#’s “generics” capabilities and iterators.) A List of references to objects of class TwoDimensionalShape, for example, could contain references to objects from derived classes Square, Circle, Triangle and so on. Calling method Draw for each TwoDimensionalShape object off a TwoDimensionalShape variable would polymorphically draw each object correctly on the screen.

Class Employee (Fig. 12.4) provides methods Earnings and ToString, in addition to the auto-implemented properties that manipulate Employee’s data. An Earnings method certainly applies generically to all employees. But each earnings calculation depends on the employee’s class. So we declare Earnings as abstract in base class Employee, because a default implementation does not make sense for that method—there’s not enough information to determine what amount Earnings should return. Each derived class overrides Earnings with an appropriate implementation. To calculate an employee’s earnings, the application assigns a reference to the employee’s object to a base class Employee variable, then invokes the Earnings method on that variable. We maintain an array of Employee variables, each of which holds a reference to an Employee object (of course, there cannot be Employee objects because Employee is an abstract class—because of inheritance, however, all objects of all derived classes of Employee may nevertheless be thought of as Employee objects). The application iterates through the array and calls method Earnings for each Employee object. C# processes these method calls polymorphically. Including Earnings as an abstract method in Employee forces every directly derived concrete class of Employee to override Earnings with a method that performs an appropriate pay calculation.

Method ToString in class Employee returns a string containing the employee’s first name, last name and social security number. Each derived class of Employee overrides method ToString to create a string representation of an object of that class containing the employee’s type (e.g., "salaried employee:"), followed by the rest of the employee’s information.

The diagram in Fig. 12.3 shows each of the five classes in the hierarchy down the left side and methods Earnings and ToString across the top. For each class, the diagram shows the desired results of each method. [Note: We do not list base class Employee’s properties because they’re not overridden in any of the derived classes—each of these properties is inherited and used “as is” by each of the derived classes.]

Figure 12.3. Polymorphic interface for the Employee hierarchy classes.

Let’s consider class Employee’s declaration (Fig. 12.4). The class includes a constructor that takes the first name, last name and social security number as arguments (lines 15–20); read-only properties for obtaining the first name, last name and social security number (lines 6, 9 and 12, respectively); method ToString (lines 23–27), which uses properties to return the string representation of the Employee; and abstract method Earnings (line 30), which must be implemented by concrete derived classes. The Employee constructor does not validate the social security number in this example. Normally, such validation should be provided.

 1   // Fig. 12.4: Employee.cs
 2   // Employee abstract base class.
 3   public abstract class Employee
 4   {
 5      // read-only property that gets employee's first name
 6      public string FirstName { get; private set; }
 7
 8      // read-only property that gets employee's last name
 9      public string LastName { get; private set; }
10
11      // read-only property that gets employee's social security number
12      public string SocialSecurityNumber { get; private set; }
13
14      // three-parameter constructor
15      public Employee( string first, string last, string ssn )
16      {
17         FirstName = first;
18         LastName = last;
19         SocialSecurityNumber = ssn;
20      } // end three-parameter Employee constructor
21
22      // return string representation of Employee object, using properties
23      public override string ToString()
24      {
25         return string.Format( "{0} {1}
social security number: {2}",
26            FirstName, LastName, SocialSecurityNumber );
27      } // end method ToString
28
29      // abstract method overridden by derived classes
30      public abstract decimal Earnings(); // no implementation here
31   } // end abstract class Employee

Why did we declare Earnings as an abstract method? As explained earlier, it simply does not make sense to provide an implementation of this method in class Employee. We cannot calculate the earnings for a general Employee—we first must know the specific Employee type to determine the appropriate earnings calculation. By declaring this method abstract, we indicate that each concrete derived class must provide an appropriate Earnings implementation and that an application will be able to use base-class Employee variables to invoke method Earnings polymorphically for any type of Employee.

Class SalariedEmployee (Fig. 12.5) extends class Employee (line 5) and overrides Earnings (lines 34–37), which makes SalariedEmployee a concrete class. The class includes a constructor (lines 10–14) that takes a first name, a last name, a social security number and a weekly salary as arguments; property WeeklySalary (lines 17–31) to manipulate instance variable weeklySalary, including a set accessor that ensures we assign only nonnegative values to weeklySalary; method Earnings (lines 34–37) to calculate a SalariedEmployee’s earnings; and method ToString (lines 40–44), which returns a string including the employee’s type, namely, "salaried employee:", followed by employee-specific information produced by base class Employee’s ToString method and SalariedEmployee’s WeeklySalary property. Class SalariedEmployee’s constructor passes the first name, last name and social security number to the Employee constructor (line 11) via a constructor initializer to initialize the base class’s data. Method Earnings overrides Employee’s abstract method Earnings to provide a concrete implementation that returns the SalariedEmployee’s weekly salary. If we do not implement Earnings, class SalariedEmployee must be declared abstract—otherwise, a compilation error occurs (and, of course, we want SalariedEmployee to be a concrete class).

 1   // Fig. 12.5: SalariedEmployee.cs
 2   // SalariedEmployee class that extends Employee.
 3   using System;
 4
 5   public class SalariedEmployee : Employee
 6   {
 7      private decimal weeklySalary;
 8
 9      // four-parameter constructor
10      public SalariedEmployee( string first, string last, string ssn,
11         decimal salary ) : base( first, last, ssn )
12      {
13         WeeklySalary = salary; // validate salary via property
14      } // end four-parameter SalariedEmployee constructor
15
16      // property that gets and sets salaried employee's salary
17      public decimal WeeklySalary
18      {
19         get
20         {
21            return weeklySalary;
22         } // end get
23         set
24         {
25            if ( value >= 0 ) // validation
26               weeklySalary = value;
27            else
28               throw new ArgumentOutOfRangeException( "WeeklySalary",
29                  value, "WeeklySalary must be >= 0" );
30         } // end set
31      } // end property WeeklySalary
32
33      // calculate earnings; override abstract method Earnings in Employee
34      public override decimal Earnings()
35      {                                 
36         return WeeklySalary;           
37      } // end method Earnings          
38
39      // return string representation of SalariedEmployee object
40      public override string ToString()                             
41      {                                                             
42         return string.Format( "salaried employee: {0}
{1}: {2:C}",
43            base.ToString(), "weekly salary", WeeklySalary );       
44      } // end method ToString                                      
45   } // end class SalariedEmployee

SalariedEmployee method ToString (lines 40–44) overrides Employee’s version. If class SalariedEmployee did not override ToString, SalariedEmployee would have inherited the Employee version. In that case, SalariedEmployee’s ToString method would simply return the employee’s full name and social security number, which does not adequately represent a SalariedEmployee. To produce a complete string representation of a SalariedEmployee, the derived class’s ToString method returns "salaried employee: ", followed by the base-class Employee-specific information (i.e., first name, last name and social security number) obtained by invoking the base class’s ToString (line 43)—this is a nice example of code reuse. The string representation of a SalariedEmployee also contains the employee’s weekly salary, obtained by using the class’s WeeklySalary property.

Class HourlyEmployee (Fig. 12.6) also extends class Employee (line 5). The class includes a constructor (lines 11–17) that takes as arguments a first name, a last name, a social security number, an hourly wage and the number of hours worked. Lines 20–34 and 37–51 declare properties Wage and Hours for instance variables wage and hours, respectively. The set accessor in property Wage ensures that wage is nonnegative, and the set accessor in property Hours ensures that hours is in the range 0 – 168 (the total number of hours in a week) inclusive. The class overrides method Earnings (lines 54–60) to calculate an HourlyEmployee’s earnings and method ToString (lines 63–68) to return the employee’s string representation. The HourlyEmployee constructor, similarly to the SalariedEmployee constructor, passes the first name, last name and social security number to the base-class Employee constructor (line 13) to initialize the base class’s data. Also, method ToString calls base-class method ToString (line 67) to obtain the Employee-specific information (i.e., first name, last name and social security number.

 1   // Fig. 12.6: HourlyEmployee.cs
 2   // HourlyEmployee class that extends Employee.
 3   using System;
 4
 5   public class HourlyEmployee : Employee
 6   {
 7      private decimal wage; // wage per hour
 8      private decimal hours; // hours worked for the week
 9
10      // five-parameter constructor
11      public HourlyEmployee( string first, string last, string ssn,
12         decimal hourlyWage, decimal hoursWorked )
13         : base( first, last, ssn )
14      {
15         Wage = hourlyWage; // validate hourly wage via property
16         Hours = hoursWorked; // validate hours worked via property
17      } // end five-parameter HourlyEmployee constructor
18
19      // property that gets and sets hourly employee's wage
20      public decimal Wage
21      {
22         get
23         {
24            return wage;
25         } // end get
26         set
27         {
28            if ( value >= 0 ) // validation
29               wage = value;
30            else
31               throw new ArgumentOutOfRangeException( "Wage",
32                  value, "Wage must be >= 0" );
33         } // end set
34      } // end property Wage
35
36      // property that gets and sets hourly employee's hours
37      public decimal Hours
38      {
39         get
40         {
41            return hours;
42         } // end get
43         set
44         {
45            if ( value >= 0 && value <= 168 ) // validation
46               hours = value;
47            else
48               throw new ArgumentOutOfRangeException( "Hours",
49                  value, "Hours must be >= 0 and <= 168" );
50         } // end set
51      } // end property Hours
52
53      // calculate earnings; override Employee's abstract method Earnings
54      public override decimal Earnings()                            
55      {                                                             
56         if ( Hours <= 40 ) // no overtime                          
57            return Wage * Hours;                                    
58         else                                                       
59            return ( 40 * Wage ) + ( ( Hours - 40 ) * Wage * 1.5M );
60      } // end method Earnings                                      
61
62      // return string representation of HourlyEmployee object
63      public override string ToString()                                   
64      {                                                                   
65         return string.Format(                                            
66            "hourly employee: {0}
{1}: {2:C}; {3}: {4:F2}",              
67            base.ToString(), "hourly wage", Wage, "hours worked", Hours );
68      } // end method ToString                                            
69   } // end class HourlyEmployee

Class CommissionEmployee (Fig. 12.7) extends class Employee (line 5). The class includes a constructor (lines 11–16) that takes a first name, a last name, a social security number, a sales amount and a commission rate; properties (lines 19–33 and 36–50) for instance variables grossSales and commissionRate, respectively; method Earnings (lines 53–56) to calculate a CommissionEmployee’s earnings; and method ToString (lines 59–64), which returns the employee’s string representation. The CommissionEmployee’s constructor also passes the first name, last name and social security number to the Employee constructor (line 12) to initialize Employee’s data. Method ToString calls base-class method ToString (line 62) to obtain the Employee-specific information (i.e., first name, last name and social security number).

 1   // Fig. 12.7: CommissionEmployee.cs
 2   // CommissionEmployee class that extends Employee.
 3   using System;
 4
 5   public class CommissionEmployee : Employee
 6   {
 7      private decimal grossSales; // gross weekly sales
 8      private decimal commissionRate; // commission percentage
 9
10      // five-parameter constructor
11      public CommissionEmployee( string first, string last, string ssn,
12         decimal sales, decimal rate ) : base( first, last, ssn )
13      {
14         GrossSales = sales; // validate gross sales via property
15         CommissionRate = rate; // validate commission rate via property
16      } // end five-parameter CommissionEmployee constructor
17
18      // property that gets and sets commission employee's gross sales
19      public decimal GrossSales
20      {
21         get
22         {
23            return grossSales;
24         } // end get
25         set
26         {
27            if ( value >= 0 )
28               grossSales = value;
29            else
30               throw new ArgumentOutOfRangeException(
31                  "GrossSales", value, "GrossSales must be >= 0" );
32         } // end set
33      } // end property GrossSales
34
35      // property that gets and sets commission employee's commission rate
36      public decimal CommissionRate
37      {
38         get
39         {
40            return commissionRate;
41         } // end get
42         set
43         {
44            if ( value > 0 && value < 1 )
45               commissionRate = value;
46            else
47               throw new ArgumentOutOfRangeException( "CommissionRate",
48                  value, "CommissionRate must be > 0 and < 1" );
49         } // end set
50      } // end property CommissionRate
51
52      // calculate earnings; override abstract method Earnings in Employee
53      public override decimal Earnings()    
54      {                                     
55         return CommissionRate * GrossSales;
56      } // end method Earnings              
57
58      // return string representation of CommissionEmployee object
59      public override string ToString()                                    
60      {                                                                    
61         return string.Format( "{0}: {1}
{2}: {3:C}
{4}: {5:F2}",        
62            "commission employee", base.ToString(),                        
63            "gross sales", GrossSales, "commission rate", CommissionRate );
64      } // end method ToString                                             
65   } // end class CommissionEmployee

Class BasePlusCommissionEmployee (Fig. 12.8) extends class CommissionEmployee (line 5) and therefore is an indirect derived class of class Employee. Class BasePlusCommissionEmployee has a constructor (lines 10–15) that takes as arguments a first name, a last name, a social security number, a sales amount, a commission rate and a base salary. It then passes the first name, last name, social security number, sales amount and commission rate to the CommissionEmployee constructor (line 12) to initialize the base class’s data. BasePlusCommissionEmployee also contains property BaseSalary (lines 19–33) to manipulate instance variable baseSalary. Method Earnings (lines 36–39) calculates a BasePlusCommissionEmployee’s earnings. Line 38 in method Earnings calls base class CommissionEmployee’s Earnings method to calculate the commission-based portion of the employee’s earnings. Again, this shows the benefits of code reuse. BasePlusCommissionEmployee’s ToString method (lines 42–46) creates a string representation of a BasePlusCommissionEmployee that contains "base-salaried", followed by the string obtained by invoking base class CommissionEmployee’s ToString method (another example of code reuse), then the base salary. The result is a string beginning with "base-salaried commission employee", followed by the rest of the BasePlusCommissionEmployee’s information. Recall that CommissionEmployee’s ToString method obtains the employee’s first name, last name and social security number by invoking the ToString method of its base class (i.e., Employee)—a further demonstration of code reuse. BasePlusCommissionEmployee’s ToString initiates a chain of method calls that spans all three levels of the Employee hierarchy.

 1   // Fig. 12.8: BasePlusCommissionEmployee.cs
 2   // BasePlusCommissionEmployee class that extends CommissionEmployee.
 3   using System;
 4
 5   public class BasePlusCommissionEmployee : CommissionEmployee
 6   {
 7      private decimal baseSalary; // base salary per week
 8
 9      // six-parameter constructor
10      public BasePlusCommissionEmployee( string first, string last,
11         string ssn, decimal sales, decimal rate, decimal salary )
12         : base( first, last, ssn, sales, rate )
13      {
14         BaseSalary = salary; // validate base salary via property
15      } // end six-parameter BasePlusCommissionEmployee constructor
16
17      // property that gets and sets
18      // base-salaried commission employee's base salary
19      public decimal BaseSalary
20      {
21         get
22         {
23            return baseSalary;
24         } // end get
25         set
26         {
27            if ( value >= 0 )
28               baseSalary = value;
29            else
30               throw new ArgumentOutOfRangeException( "BaseSalary",
31                  value, "BaseSalary must be >= 0" );
32         } // end set
33      } // end property BaseSalary
34
35      // calculate earnings; override method Earnings in CommissionEmployee
36      public override decimal Earnings()     
37      {                                      
38         return BaseSalary + base.Earnings();
39      } // end method Earnings               
40
41      // return string representation of BasePlusCommissionEmployee object
42      public override string ToString()                                   
43      {                                                                   
44         return string.Format( "base-salaried {0}; base salary: {1:C}",   
45            base.ToString(), BaseSalary );                                
46      } // end method ToString                                            
47   } // end class BasePlusCommissionEmployee

To test our Employee hierarchy, the application in Fig. 12.9 creates an object of each of the four concrete classes SalariedEmployee, HourlyEmployee, CommissionEmployee and BasePlusCommissionEmployee. The application manipulates these objects, first via variables of each object’s own type, then polymorphically, using an array of Employee variables. While processing the objects polymorphically, the application increases the base salary of each BasePlusCommissionEmployee by 10% (this, of course, requires determining the object’s type at execution time). Finally, the application polymorphically determines and outputs the type of each object in the Employee array. Lines 10–20 create objects of each of the four concrete Employee derived classes. Lines 24–32 output the string representation and earnings of each of these objects. Each object’s ToString method is called implicitly by WriteLine when the object is output as a string with format items.

 1   // Fig. 12.9: PayrollSystemTest.cs
 2   // Employee hierarchy test application.
 3   using System;
 4
 5   public class PayrollSystemTest
 6   {
 7      public static void Main( string[] args )
 8      {
 9         // create derived-class objects
10         SalariedEmployee salariedEmployee =                                
11            new SalariedEmployee( "John", "Smith", "111-11-1111", 800.00M );
12         HourlyEmployee hourlyEmployee =                                    
13            new HourlyEmployee( "Karen", "Price",                           
14            "222-22-2222", 16.75M, 40.0M );                                
15         CommissionEmployee commissionEmployee =                            
16            new CommissionEmployee( "Sue", "Jones",                         
17            "333-33-3333", 10000.00M, .06M );                               
18         BasePlusCommissionEmployee basePlusCommissionEmployee =            
19            new BasePlusCommissionEmployee( "Bob", "Lewis",                 
20            "444-44-4444", 5000.00M, .04M, 300.00M );                       
21
22         Console.WriteLine( "Employees processed individually:
" );
23
24         Console.WriteLine( "{0}
earned: {1:C}
",
25            salariedEmployee, salariedEmployee.Earnings() );
26         Console.WriteLine( "{0}
earned: {1:C}
",
27            hourlyEmployee, hourlyEmployee.Earnings() );
28         Console.WriteLine( "{0}
earned: {1:C}
",
29            commissionEmployee, commissionEmployee.Earnings() );
30         Console.WriteLine( "{0}
earned: {1:C}
",
31            basePlusCommissionEmployee,
32            basePlusCommissionEmployee.Earnings() );
33
34         // create four-element Employee array
35         Employee[] employees = new Employee[ 4 ];
36
37         // initialize array with Employees of derived types
38         employees[ 0 ] = salariedEmployee;          
39         employees[ 1 ] = hourlyEmployee;            
40         employees[ 2 ] = commissionEmployee;        
41         employees[ 3 ] = basePlusCommissionEmployee;
42
43         Console.WriteLine( "Employees processed polymorphically:
" );
44
45         // generically process each element in array employees
46         foreach ( Employee currentEmployee in employees )
47         {
48            Console.WriteLine( currentEmployee ); // invokes ToString
49
50            // determine whether element is a BasePlusCommissionEmployee
51            if ( currentEmployee is BasePlusCommissionEmployee )
52            {
53               // downcast Employee reference to
54               // BasePlusCommissionEmployee reference
55               BasePlusCommissionEmployee employee =
56                  ( BasePlusCommissionEmployee ) currentEmployee;
57
58               employee.BaseSalary *= 1.10M ;
59               Console.WriteLine(
60                  "new base salary with 10% increase is: {0:C}",
61                  employee.BaseSalary );
62            } // end if
63
64            Console.WriteLine(
65               "earned {0:C}
", currentEmployee.Earnings() );
66         } // end foreach
67
68         // get type name of each object in employees array
69         for ( int j = 0 ; j < employees.Length; j++ )    
70            Console.WriteLine( "Employee {0} is a {1}", j,
71               employees[ j ].GetType() );                
72      } // end Main
73   } // end class PayrollSystemTest

Employees processed individually:

salaried employee: John Smith
social security number: 111-11-1111
weekly salary: $800.00
earned: $800.00

hourly employee: Karen Price
social security number: 222-22-2222
hourly wage: $16.75; hours worked: 40.00
earned: $670.00

commission employee: Sue Jones
social security number: 333-33-3333
gross sales: $10,000.00
commission rate: 0.06
earned: $600.00

base-salaried commission employee: Bob Lewis
social security number: 444-44-4444
gross sales: $5,000.00
commission rate: 0.04; base salary: $300.00
earned: $500.00

Employees processed polymorphically:

salaried employee: John Smith
social security number: 111-11-1111
weekly salary: $800.00
earned $800.00

hourly employee: Karen Price
social security number: 222-22-2222
hourly wage: $16.75; hours worked: 40.00
earned $670.00
commission employee: Sue Jones
social security number: 333-33-3333
gross sales: $10,000.00
commission rate: 0.06
earned $600.00

base-salaried commission employee: Bob Lewis
social security number: 444-44-4444
gross sales: $5,000.00
commission rate: 0.04; base salary: $300.00
new base salary with 10% increase is: $330.00
earned $530.00

Employee 0 is a SalariedEmployee
Employee 1 is a HourlyEmployee
Employee 2 is a CommissionEmployee
Employee 3 is a BasePlusCommissionEmployee

Line 35 declares employees and assigns it an array of four Employee variables. Lines 38–41 assign a SalariedEmployee object, an HourlyEmployee object, a CommissionEmployee object and a BasePlusCommissionEmployee object to employees[0], employees[1], employees[2] and employees[3], respectively. Each assignment is allowed, because a SalariedEmployee is an Employee, an HourlyEmployee is an Employee, a CommissionEmployee is an Employee and a BasePlusCommissionEmployee is an Employee. Therefore, we can assign the references of SalariedEmployee, HourlyEmployee, CommissionEmployee and BasePlusCommissionEmployee objects to base-class Employee variables, even though Employee is an abstract class.

Giving BasePlusCommissionEmployees 10% Raises

We perform special processing on BasePlusCommissionEmployee objects—as we encounter them, we increase their base salary by 10%. When processing objects polymorphically, we typically do not need to worry about the “specifics,” but to adjust the base salary, we do have to determine the specific type of each Employee object at execution time. Line 51 uses the is operator to determine whether a particular Employee object’s type is BasePlusCommissionEmployee. The condition in line 51 is true if the object referenced by currentEmployee is a BasePlusCommissionEmployee. This would also be true for any object of a BasePlusCommissionEmployee derived class (if there were any), because of the is-a relationship a derived class has with its base class. Lines 55–56 downcast currentEmployee from type Employee to type BasePlusCommissionEmployee—this cast is allowed only if the object has an is-a relationship with BasePlusCommissionEmployee. The condition at line 51 ensures that this is the case. This cast is required if we are to use derived class BasePlusCommissionEmployee’s BaseSalary property on the current Employee object—attempting to invoke a derived-class-only method directly on a base class reference is a compilation error.

Common Programming Error 12.3

Assigning a base-class variable to a derived-class variable (without an explicit downcast) is a compilation error.

Software Engineering Observation 12.4

If at execution time the reference to a derived-class object has been assigned to a variable of one of its direct or indirect base classes, it’s acceptable to cast the reference stored in that base-class variable back to a reference of the derived-class type. Before performing such a cast, use the is operator to ensure that the object is indeed an object of an appropriate derived-class type.

When downcasting an object, an InvalidCastException (of namespace System) occurs if at execution time the object does not have an is a relationship with the type specified in the cast operator. An object can be cast only to its own type or to the type of one of its base classes. You can avoid a potential InvalidCastException by using the as operator to perform a downcast rather than a cast operator. For example, in the statement

BasePlusCommissionEmployee employee = currentEmployee as BasePlusCommissionEmployee;

employee is assigned a reference to an object that is a BasePlusCommissionEmployee, or the value null if currentEmployee is not a BasePlusCommissionEmployee. You can then compare employee with null to determine whether the cast succeeded.

If the is expression in line 51 is true, the if statement (lines 51–62) performs the special processing required for the BasePlusCommissionEmployee object. Using BasePlusCommissionEmployee variable employee, line 58 accesses the derived-class-only property BaseSalary to retrieve and update the employee’s base salary with the 10% raise.

Lines 64–65 invoke method Earnings on currentEmployee, which calls the appropriate derived-class object’s Earnings method polymorphically. Obtaining the earnings of the SalariedEmployee, HourlyEmployee and CommissionEmployee polymorphically in lines 64–65 produces the same result as obtaining these employees’ earnings individually in lines 24–29. However, the earnings amount obtained for the BasePlusCommissionEmployee in lines 64–65 is higher than that obtained in lines 30–32, due to the 10% increase in its base salary.

Now that you’ve seen a complete application that processes diverse derived-class objects polymorphically, we summarize what you can and cannot do with base-class and derivedclass objects and variables. Although a derived-class object also is a base-class object, the two are nevertheless different. As discussed previously, derived-class objects can be treated as if they were base-class objects. However, the derived class can have additional derived-class-only members. For this reason, assigning a base-class reference to a derived-class variable is not allowed without an explicit cast—such an assignment would leave the derivedclass members undefined for a base-class object.

We’ve discussed four ways to assign base-class and derived-class references to variables of base-class and derived-class types:

To build an application that can determine payments for employees and invoices alike, we first create an interface named IPayable. Interface IPayable contains method GetPaymentAmount that returns a decimal amount to be paid for an object of any class that implements the interface. Method GetPaymentAmount is a general-purpose version of method Earnings of the Employee hierarchy—method Earnings calculates a payment amount specifically for an Employee, while GetPaymentAmount can be applied to a broad range of unrelated objects. After declaring interface IPayable, we introduce class Invoice, which implements interface IPayable. We then modify class Employee such that it also implements interface IPayable. Finally, we update Employee derived class SalariedEmployee to “fit” into the IPayable hierarchy (i.e., we rename SalariedEmployee method Earnings as GetPaymentAmount).

Good Programming Practice 12.1

By convention, the name of an interface begins with “I”. This helps distinguish interfaces from classes, improving code readability.

Good Programming Practice 12.2

When declaring a method in an interface, choose a name that describes the method’s purpose in a general manner, because the method may be implemented by a broad range of unrelated classes.

Classes Invoice and Employee both represent things for which the company must be able to calculate a payment amount. Both classes implement IPayable, so an application can invoke method GetPaymentAmount on Invoice objects and Employee objects alike. This enables the polymorphic processing of Invoices and Employees required for our company’s accounts-payable application.

The UML class diagram in Fig. 12.10 shows the interface and class hierarchy used in our accounts-payable application. The hierarchy begins with interface IPayable. The UML distinguishes an interface from a class by placing the word “interface” in guillemets (« and ») above the interface name. The UML expresses the relationship between a class and an interface through a realization. A class is said to “realize,” or implement, an interface. A class diagram models a realization as a dashed arrow with a hollow arrowhead pointing from the implementing class to the interface. The diagram in Fig. 12.10 indicates that classes Invoice and Employee each realize (i.e., implement) interface IPayable. As in the class diagram of Fig. 12.2, class Employee appears in italics, indicating that it’s an abstract class. Concrete class SalariedEmployee extends Employee and inherits its base class’s realization relationship with interface IPayable.

Figure 12.10. IPayable interface and class hierarchy UML class diagram.

The declaration of interface IPayable begins in Fig. 12.11 at line 3. Interface IPayable contains public abstract method GetPaymentAmount (line 5). The method cannot be explicitly declared public or abstract. Interfaces can have any number of members and interface methods can have parameters.

 1   // Fig. 12.11: IPayable.cs
 2   // IPayable interface declaration.
 3   public interface IPayable
 4   {
 5      decimal GetPaymentAmount(); // calculate payment; no implementation
 6   } // end interface IPayable

We now create class Invoice (Fig. 12.12) to represent a simple invoice that contains billing information for one kind of part. The class contains properties PartNumber (line 11), PartDescription (line 14), Quantity (lines 27–41) and PricePerItem (lines 44–58) that indicate the part number, the description of the part, the quantity of the part ordered and the price per item. Class Invoice also contains a constructor (lines 17–24) and a ToString method (lines 61–67) that returns a string representation of an Invoice object. The set accessors of properties Quantity and PricePerItem ensure that quantity and pricePerItem are assigned only nonnegative values.

 1   // Fig. 12.12: Invoice.cs
 2   // Invoice class implements IPayable.
 3   using System;
 4
 5   public class Invoice : IPayable
 6   {
 7      private int quantity;
 8      private decimal pricePerItem;
 9
10      // property that gets and sets the part number on the invoice
11      public string PartNumber { get; set; }
12
13      // property that gets and sets the part description on the invoice
14      public string PartDescription { get; set; }
15
16      // four-parameter constructor
17      public Invoice( string part, string description, int count,
18         decimal price )
19      {
20         PartNumber = part;
21         PartDescription = description;
22         Quantity = count; // validate quantity via property
23         PricePerItem = price; // validate price per item via property
24      } // end four-parameter Invoice constructor
25
26      // property that gets and sets the quantity on the invoice
27      public int Quantity
28      {
29         get
30         {
31            return quantity;
32         } // end get
33         set
34         {
35            if ( value >= 0 ) // validate quantity
36               quantity = value;
37            else
38               throw new ArgumentOutOfRangeException( "Quantity",
39                  value, "Quantity must be >= 0" );
40         } // end set
41      } // end property Quantity
42
43      // property that gets and sets the price per item
44      public decimal PricePerItem
45      {
46         get
47         {
48            return pricePerItem;
49         } // end get
50         set
51         {
52            if ( value >= 0 ) // validate price
53               quantity = value;
54            else
55               throw new ArgumentOutOfRangeException( "PricePerItem",
56                  value, "PricePerItem must be >= 0" );
57         } // end set
58      } // end property PricePerItem
59
60      // return string representation of Invoice object
61      public override string ToString()
62      {
63         return string.Format(
64            "{0}: 
{1}: {2} ({3}) 
{4}: {5} 
{6}: {7:C}",
65            "invoice", "part number", PartNumber, PartDescription,
66            "quantity", Quantity, "price per item", PricePerItem );
67      } // end method ToString
68
69      // method required to carry out contract with interface IPayable
70      public decimal GetPaymentAmount()                         
71      {                                                         
72         return Quantity * PricePerItem; // calculate total cost
73      } // end method GetPaymentAmount                          
74   } // end class Invoice

Line 5 of Fig. 12.12 indicates that class Invoice implements interface IPayable. Like all classes, class Invoice also implicitly inherits from class object. C# does not allow derived classes to inherit from more than one base class, but it does allow a class to inherit from a base class and implement any number of interfaces. All objects of a class that implement multiple interfaces have the is-a relationship with each implemented interface type. To implement more than one interface, use a comma-separated list of interface names after the colon (:) in the class declaration, as in:

public class ClassName : BaseClassName, FirstInterface, SecondInterface, ...

When a class inherits from a base class and implements one or more interfaces, the class declaration must list the base-class name before any interface names.

Class Invoice implements the one method in interface IPayable—method GetPaymentAmount is declared in lines 70–73. The method calculates the amount required to pay the invoice. The method multiplies the values of quantity and pricePerItem (obtained through the appropriate properties) and returns the result (line 72). This method satisfies the implementation requirement for the method in interface IPayable—we’ve fulfilled the interface contract with the compiler.

We now modify class Employee to implement interface IPayable. Figure 12.13 contains the modified Employee class. This class declaration is identical to that of Fig. 12.4 with two exceptions. First, line 3 of Fig. 12.13 indicates that class Employee now implements interface IPayable. Because of this, we must rename Earnings to GetPaymentAmount throughout the Employee hierarchy. As with method Earnings in the version of class Employee in Fig. 12.4, however, it does not make sense to implement method GetPaymentAmount in class Employee, because we cannot calculate the earnings payment owed to a general Employee—first, we must know the specific type of Employee. In Fig. 12.4, we declared method Earnings as abstract for this reason, and as a result, class Employee had to be declared abstract. This forced each Employee derived class to override Earnings with a concrete implementation.

 1   // Fig. 12.13: Employee.cs
 2   // Employee abstract base class.
 3   public abstract class Employee : IPayable
 4   {
 5      // read-only property that gets employee's first name
 6      public string FirstName { get; private set; }
 7
 8      // read-only property that gets employee's last name
 9      public string LastName { get; private set; }
10
11      // read-only property that gets employee's social security number
12      public string SocialSecurityNumber { get; private set; }
13
14      // three-parameter constructor
15      public Employee( string first, string last, string ssn )
16      {
17         FirstName = first;
18         LastName = last;
19         SocialSecurityNumber = ssn;
20      } // end three-parameter Employee constructor
21
22      // return string representation of Employee object
23      public override string ToString()
24      {
25         return string.Format( "{0} {1}
social security number: {2}",
26            FirstName, LastName, SocialSecurityNumber );
27      } // end method ToString
28
29      // Note: We do not implement IPayable method GetPaymentAmount here, so
30      // this class must be declared abstract to avoid a compilation error. 
31      public abstract decimal GetPaymentAmount();                           
32   } // end abstract class Employee

In Fig. 12.13, we handle this situation the same way. Recall that when a class implements an interface, the class makes a contract with the compiler stating that the class either will implement each of the methods in the interface or will declare them abstract. If the latter option is chosen, we must also declare the class abstract. As we discussed in Section 12.4, any concrete derived class of the abstract class must implement the abstract methods of the base class. If the derived class does not do so, it too must be declared abstract. As indicated by the comments in lines 29–30, class Employee of Fig. 12.13 does not implement method GetPaymentAmount, so the class is declared abstract.

Figure 12.14 contains a modified version of class SalariedEmployee that extends Employee and implements method GetPaymentAmount. This version of SalariedEmployee is identical to that of Fig. 12.5 with the exception that the version here implements method GetPaymentAmount (lines 35–38) instead of method Earnings. The two methods contain the same functionality but have different names. Recall that the IPayable version of the method has a more general name to be applicable to possibly disparate classes. The remaining Employee derived classes (e.g., HourlyEmployee, CommissionEmployee and BasePlusCommissionEmployee) also must be modified to contain method GetPaymentAmount in place of Earnings to reflect the fact that Employee now implements IPayable. We leave these modifications as an exercise and use only SalariedEmployee in our test application in this section.

 1   // Fig. 12.14: SalariedEmployee.cs
 2   // SalariedEmployee class that extends Employee.
 3   using System;
 4
 5   public class SalariedEmployee : Employee
 6   {
 7      private decimal weeklySalary;
 8
 9      // four-parameter constructor
10      public SalariedEmployee( string first, string last, string ssn,
11         decimal salary ) : base( first, last, ssn )
12      {
13         WeeklySalary = salary; // validate salary via property
14      } // end four-parameter SalariedEmployee constructor
15
16      // property that gets and sets salaried employee's salary
17      public decimal WeeklySalary
18      {
19         get
20         {
21            return weeklySalary;
22         } // end get
23         set
24         {
25            if ( value >= 0 ) // validation
26               weeklySalary = value;
27            else
28               throw new ArgumentOutOfRangeException( "WeeklySalary",
29                  value, "WeeklySalary must be >= 0" );
30         } // end set
31      } // end property WeeklySalary
32
33      // calculate earnings; implement interface IPayable method
34      // that was abstract in base class Employee
35      public override decimal GetPaymentAmount()
36      {                                         
37         return WeeklySalary;                   
38      } // end method GetPaymentAmount          
39
40      // return string representation of SalariedEmployee object
41      public override string ToString()
42      {
43         return string.Format( "salaried employee: {0}
{1}: {2:C}",
44            base.ToString(), "weekly salary", WeeklySalary );
45      } // end method ToString
46   } // end class SalariedEmployee

When a class implements an interface, the same is-a relationship provided by inheritance applies. Class Employee implements IPayable, so we can say that an Employee is an IPayable, as are any classes that extend Employee. As such, SalariedEmployee objects are IPayable objects. An object of a class that implements an interface may be thought of as an object of the interface type. Objects of any classes derived from the class that implements the interface can also be thought of as objects of the interface type. Thus, just as we can assign the reference of a SalariedEmployee object to a base-class Employee variable, we can assign the reference of a SalariedEmployee object to an interface IPayable variable. Invoice implements IPayable, so an Invoice object also is an IPayable object, and we can assign the reference of an Invoice object to an IPayable variable.

Software Engineering Observation 12.5

Inheritance and interfaces are similar in their implementation of the is-a relationship. An object of a class that implements an interface may be thought of as an object of that interface type. An object of any derived classes of a class that implements an interface also can be thought of as an object of the interface type.

Software Engineering Observation 12.6

The is-a relationship that exists between base classes and derived classes, and between interfaces and the classes that implement them, holds when passing an object to a method. When a method parameter receives an argument of a base class or interface type, the method polymorphically processes the object received as an argument.

PayableInterfaceTest (Fig. 12.15) illustrates that interface IPayable can be used to process a set of Invoices and Employees polymorphically in a single application. Line 10 declares payableObjects and assigns it an array of four IPayable variables. Lines 13–14 assign the references of Invoice objects to the first two elements of payableObjects. Lines 15–18 assign the references of SalariedEmployee objects to the remaining two elements of payableObjects. These assignments are allowed because an Invoice is an IPayable, a SalariedEmployee is an Employee and an Employee is an IPayable. Lines 24–29 use a foreach statement to process each IPayable object in payableObjects polymorphically, printing the object as a string, along with the payment due. Lines 27–28 implicitly invokes method ToString off an IPayable interface reference, even though ToString is not declared in interface IPayable—all references (including those of interface types) refer to objects that extend object and therefore have a ToString method. Line 28 invokes IPayable method GetPaymentAmount to obtain the payment amount for each object in payableObjects, regardless of the actual type of the object. The output reveals that the method calls in lines 27–28 invoke the appropriate class’s implementation of methods ToString and GetPaymentAmount. For instance, when currentPayable refers to an Invoice during the first iteration of the foreach loop, class Invoice’s ToString and GetPaymentAmount methods execute.

 1   // Fig. 12.15: PayableInterfaceTest.cs
 2   // Tests interface IPayable with disparate classes.
 3   using System;
 4
 5   public class PayableInterfaceTest
 6   {
 7      public static void Main( string[] args )
 8      {
 9         // create four-element IPayable array
10         IPayable[] payableObjects = new IPayable[ 4 ];
11
12         // populate array with objects that implement IPayable
13         payableObjects[ 0 ] = new Invoice( "01234", "seat", 2, 375.00M );
14         payableObjects[ 1 ] = new Invoice( "56789", "tire", 4, 79.95M );
15         payableObjects[ 2 ] = new SalariedEmployee( "John", "Smith",
16            "111-11-1111", 800.00M );
17         payableObjects[ 3 ] = new SalariedEmployee( "Lisa", "Barnes",
18            "888-88-8888", 1200.00M );
19
20         Console.WriteLine(
21            "Invoices and Employees processed polymorphically:
" );
22
23         // generically process each element in array payableObjects
24         foreach ( var currentPayable in payableObjects )
25         {
26            // output currentPayable and its appropriate payment amount
27            Console.WriteLine( "payment due {0}: {1:C}
",
28               currentPayable, currentPayable.GetPaymentAmount() );
29         } // end foreach
30      } // end Main
31   } // end class PayableInterfaceTest

Invoices and Employees processed polymorphically:

invoice:
part number: 01234 (seat)
quantity: 2
price per item: $375.00
payment due: $750.00
invoice:

part number: 56789 (tire)
quantity: 4
price per item: $79.95
payment due: $319.80

salaried employee: John Smith
social security number: 111-11-1111
weekly salary: $800.00
payment due: $800.00

salaried employee: Lisa Barnes
social security number: 888-88-8888
weekly salary: $1,200.00
payment due: $1,200.00

Software Engineering Observation 12.7

All methods of class object can be called by using a reference of an interface type—the reference refers to an object, and all objects inherit the methods of class object.

In this section, we overview several common interfaces defined in the .NET Framework Class Library. These interfaces are implemented and used in the same manner as those you create (e.g., interface IPayable in Section 12.7.2). The Framework Class Library’s interfaces enable you to extend many important aspects of C# with your own classes. Figure 12.16 overviews several commonly used Framework Class Library interfaces.