1. Polymorphism, Interfaces & Operator Overloading11
Polymorphism, Interfaces & Operator Overloading

2. OBJECTIVES In this chapter you will learn:
The concept of polymorphism and how it enables you to "program in the general."
To use overridden methods to effect polymorphism.
To distinguish between abstract and concrete classes.
To declare abstract methods to create abstract classes.
How polymorphism makes systems extensible and maintainable.
To determine an object's type at execution time.
To create sealed methods and classes.
To declare and implement interfaces.
To overload operators to enable them to manipulate objects.

3. 11.1 Introduction
11.2 Polymorphism Examples
11.3 Demonstrating Polymorphic Behavior
11.4 Abstract Classes and Methods
11.5 Case Study: Payroll System Using Polymorphism
Creating Abstract Base Class Employee
Creating Concrete Derived Class SalariedEmployee
Creating Concrete Derived Class HourlyEmployee
Creating Concrete Derived Class CommissionEmployee
Creating Indirect Concrete Derived Class BasePlusCommissionEmployee
Polymorphic Processing, Operator is and Downcasting
Summary of the Allowed Assignments Between Base Class and Derived Class Variables

4. 11.6   sealed Methods and Classes
11.7   Case Study: Creating and Using Interfaces
11.7.1  Developing an IPayable Hierarchy
11.7.2  Declaring Interface IPayable
11.7.3  Creating Class Invoice
11.7.4  Modifying Class Employee to Implement Interface IPayable
11.7.5  Modifying Class SalariedEmployee for Use in the IPayable Hierarchy
11.7.6  Using Interface IPayable to Process Invoices and Employees Polymorphically
11.7.7  Common Interfaces of the .NET Framework Class Library
11.8   Operator Overloading
11.9   (Optional) Software Engineering Case
Study: Incorporating Inheritance and Polymorphism into the ATM System
11.10   Wrap-Up

5. Software Engineering Observation 11.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.

6. Outline
PolymorphismTest .cs
(1 of 3)

7. Outline
PolymorphismTest .cs
(2 of 3)

8. Outline
PolymorphismTest .cs
(3 of 3)

9. Software Engineering Observation 11.2
An abstract class declares common attributes and behaviors of the various classes that inherit from it, either directly or indirectly, in a class hierarchy. An abstract class typically contains one or more abstract methods or properties that concrete derived classes must override. The instance variables, concrete methods and concrete properties of an abstract class are subject to the normal rules of inheritance.

10. Common Programming Error 11.1
Attempting to instantiate an object of an abstract class is a compilation error.

11. Common Programming Error 11.2
Failure to implement a base class’s abstract methods and properties in a derived class is a compilation error unless the derived class is also declared abstract.

12. Software Engineering Observation 11.3
A derived class can inherit “interface” or “implementation” from a base class. Hierarchies designed for implementation inheritance tend to have their functionality high in the hierarchy—each new derived class inherits one or more methods that were implemented in a base class, and the derived class uses the base class implementations. Hierarchies designed for interface inheritance tend to have their functionality lower in the hierarchy—a base class specifies one or more abstract methods that must be declared for each concrete class in the hierarchy, and the individual derived classes override these methods to provide derived-class-specific implementations.

13. Fig. 11.2 | Employee hierarchy UML class diagram.

14. Fig. 11.3 | Polymorphic interface for the Employee hierarchy classes.

15. Outline
Employee.cs
(1 of 2)

16. Outline
Employee.cs
(2 of 2)

17. Outline
SalariedEmployee .cs
(1 of 2)

18. Outline
SalariedEmployee .cs
(2 of 2)

19. Outline
HourlyEmployee.cs
(1 of 3)

20. Outline
HourlyEmployee.cs
(2 of 3)

21. Outline
HourlyEmployee.cs
(3 of 3)

22. Outline
CommissionEmployee .cs
(1 of 2)

23. Outline
CommissionEmployee .cs
(2 of 2)

24. Outline
BasePlusCommission Employee.cs
(1 of 2)

25. Outline
BasePlusCommission Employee.cs
(2 of 2)

26. Outline
PayrollSystemTest. cs
(1 of 5)

27. Outline
PayrollSystemTest. cs
(2 of 5)

28. Outline
PayrollSystemTest. cs
(3 of 5)

29. Outline
PayrollSystemTest. cs
(4 of 5)

30. Outline
PayrollSystemTest. cs
(5 of 5)

31. Common Programming Error 11.3
Assigning a base class variable to a derived class variable (without an explicit downcast) is a compilation error.

32. Software Engineering Observation 11.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 is 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.

33. Common Programming Error 11.4
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.

34. Performance Tip 11.1
The compiler can decide to inline a sealed method call and will do so for small, simple sealed methods. Inlining does not violate encapsulation or information hiding, but does improve performance because it eliminates the overhead of making a method call.

35. Common Programming Error 11.5
Attempting to declare a derived class of a sealed class is a compilation error.

36. Software Engineering Observation 11.5
In the FCL, the vast majority of classes are not declared sealed. This enables inheritance and polymorphism—the fundamental capabilities of object-oriented programming.

37. Common Programming Error 11.6
It is a compilation error to declare an interface member public or abstract explicitly, because they are redundant in interface member declarations. It is also a compilation error to specify any implementation details, such as concrete method declarations, in an interface.

38. Common Programming Error 11.7
Failing to declare any member of an interface in a class that implements the interface results in a compilation error.

39. Good Programming Practice 11.1
By convention, the name of an interface begins with "I". This helps distinguish interfaces from classes, improving code readability.

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

41. Fig. 11.10 | IPayable interface and class hierarchy UML class diagram.

42. Outline
IPayable.cs

43. Outline
Invoice.cs
(1 of 4)

44. Outline
Invoice.cs
(2 of 4)

45. Outline
Invoice.cs
(3 of 4)

46. Outline
Invoice.cs
(4 of 4)

47. Outline
Employee.cs
(1 of 2)

48. Outline
Employee.cs
(2 of 2)

49. Outline
SalariedEmployee .cs
(1 of 2)

50. Outline
SalariedEmployee .cs
(2 of 2)

51. Software Engineering Observation 11.6
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.

52. Software Engineering Observation 11.7
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 a variable of a base class or interface type, the method polymorphically processes the object received as an argument.

53. Software Engineering Observation 11.8
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.

54. Outline
PayableInterfaceTe st.cs
(1 of 2)

55. Outline
PayableInterfaceTe st.cs
(2 of 2)

56. Software Engineering Observation 11.9
Use operator overloading when it makes an application clearer than accomplishing the same operations with explicit method calls.

57. Outline
ComplexNumber.cs
(1 of 3)

58. Outline
ComplexNumber.cs
(2 of 3)

59. Outline
ComplexNumber.cs
(3 of 3)

60. Software Engineering Observation 11.10
Overload operators to perform the same function or similar functions on class objects as the operators perform on objects of simple types. Avoid non-intuitive use of operators.

61. Software Engineering Observation 11.11
At least one argument of an overloaded operator method must be a reference to an object of the class in which the operator is overloaded. This prevents programmers from changing how operators work on simple types.

62. Outline
Operator Overloading.cs
(1 of 2)

63. Outline
Operator Overloading.cs
(2 of 2)