5.3 Polymorphism

There are two powerful aspects to inheritance. One is code reuse. When you create a ListBox class, you're able to reuse some of the logic in the base (Window) class.

What is arguably more powerful, however, is the second aspect of inheritance: polymorphism. Poly means many and morph means form. Thus, polymorphism refers to being able to use many forms of a type without regard to the details.

When the phone company sends your phone a ring signal, it does not know what type of phone is on the other end of the line. You might have an old-fashioned Western Electric phone that energizes a motor to ring a bell, or you might have an electronic phone that plays digital music.

As far as the phone company is concerned, it knows only about the "base type" phone and expects that any "instance" of this type knows how to ring. When the phone company tells your phone to ring, it simply expects the phone to "do the right thing." Thus, the phone company treats your phone polymorphically.

5.3.1 Creating Polymorphic Types

Because a ListBox is-a Window and a Button is-a Window, we expect to be able to use either of these types in situations that call for a Window. For example, a form might want to keep a collection of all the instances of Window it manages so that when the form is opened, it can tell each of its Windows to draw itself. For this operation, the form does not want to know which elements are list boxes and which are buttons; it just wants to tick through its collection and tell each to "draw." In short, the form wants to treat all its Window objects polymorphically.

5.3.2 Creating Polymorphic Methods

To create a method that supports polymorphism, you need only mark it as virtual in its base class. For example, to indicate that the method DrawWindow( ) of class Window in Example 5-1 is polymorphic, simply add the keyword virtual to its declaration as follows:

public virtual void DrawWindow( )

Now each derived class is free to implement its own version of DrawWindow( ). To do so, simply override the base class virtual method by using the keyword override in the derived class method definition, and then add the new code for that overridden method.

In the following excerpt from Example 5-2 (which appears later in this section), ListBox derives from Window and implements its own version of DrawWindow( ):

public override void DrawWindow( ) {    base.DrawWindow( );  // invoke the base method    Console.WriteLine ("Writing string to the listbox: {0}",        listBoxContents); }

The keyword override tells the compiler that this class has intentionally overridden how DrawWindow( ) works. Similarly, you'll override this method in another class, Button, also derived from Window.

In the body of Example 5-2, you'll first create three objects: a Window, a ListBox, and a Button. You'll then call DrawWindow( ) on each:

Window win = new Window(1,2); ListBox lb = new ListBox(3,4,"Stand alone list box"); Button b = new Button(5,6); win.DrawWindow( ); lb.DrawWindow( ); b.DrawWindow( );

This works much as you might expect. The correct DrawWindow( ) object is called for each. So far, nothing polymorphic has been done. The real magic starts when you create an array of Window objects. Because a ListBox is-a Window, you are free to place a ListBox into a Window array. You can also place a Button into an array of Window objects because a Button is also a Window:

Window[] winArray = new Window[3]; winArray[0] = new Window(1,2); winArray[1] = new ListBox(3,4,"List box in array"); winArray[2] = new Button(5,6);

What happens when you call DrawWindow( ) on each of these objects?

for (int i = 0;i < 3; i++) {    winArray[i].DrawWindow( ); }

All the compiler knows is that it has three Window objects and that you've called DrawWindow( ) on each. If you had not marked DrawWindow as virtual, Window's DrawWindow( ) method would be called three times. However, because you did mark DrawWindow( ) as virtual, and because the derived classes override that method, when you call DrawWindow( ) on the array, the compiler determines the runtime type of the actual objects (a Window, a ListBox and a Button) and calls the right method on each. This is the essence of polymorphism. The complete code for this example is shown in Example 5-2.

This listing uses an array, which is a collection of objects of the same type. Access the members of the array with the index operator:

// set the value of the element // at offset 5 MyArray[5] = 7; 

The first element in any array is at index 0. The use of the array in this example should be fairly intuitive. Arrays are explained in detail in Chapter 9.

Example 5-2. Using virtual methods

using System; public class Window {    // these members are protected and thus visible    // to derived class methods. We'll examine this     // later in the chapter    protected int top;    protected int left;    // constructor takes two integers to    // fix location on the console    public Window(int top, int left)    {       this.top = top;       this.left = left;    }    // simulates drawing the window    public virtual void DrawWindow( )    {       Console.WriteLine("Window: drawing Window at {0}, {1}",          top, left);    } } // ListBox derives from Window public class ListBox : Window {    private string listBoxContents;  // new member variable    // constructor adds a parameter    public ListBox(       int top,        int left,        string contents):       base(top, left)  // call base constructor    {         listBoxContents = contents;    }     // an overridden version (note keyword) because in the    // derived method we change the behavior    public override void DrawWindow( )    {       base.DrawWindow( );  // invoke the base method       Console.WriteLine ("Writing string to the listbox: {0}",           listBoxContents);    } } public class Button : Window {    public Button(       int top,       int left):       base(top, left)    {    }     // an overridden version (note keyword) because in the    // derived method we change the behavior    public override void DrawWindow( )    {       Console.WriteLine("Drawing a button at {0}, {1}\n",          top, left);    } } public class Tester {    static void Main( )    {       Window win = new Window(1,2);       ListBox lb = new ListBox(3,4,"Stand alone list box");       Button b = new Button(5,6);       win.DrawWindow( );       lb.DrawWindow( );       b.DrawWindow( );       Window[] winArray = new Window[3];       winArray[0] = new Window(1,2);       winArray[1] = new ListBox(3,4,"List box in array");       winArray[2] = new Button(5,6);       for (int i = 0;i < 3; i++)       {          winArray[i].DrawWindow( );       }    } } Output: Window: drawing Window at 1, 2 Window: drawing Window at 3, 4 Writing string to the listbox: Stand alone list box Drawing a button at 5, 6 Window: drawing Window at 1, 2 Window: drawing Window at 3, 4 Writing string to the listbox: List box in array Drawing a button at 5, 6

Note that throughout this example we've marked the new overridden methods with the keyword override:

public override void DrawWindow( )

The compiler now knows to use the overridden method when treating these objects polymorphically. The compiler is responsible for tracking the real type of the object and for handling the "late binding" so that it is ListBox.DrawWindow( ) that is called when the Window reference really points to a ListBox object.

C++ programmers take note: You must explicitly mark the declaration of any method that overrides a virtual method with the keyword override.

5.3.3 Versioning with the new and override Keywords

In C#, the programmer's decision to override a virtual method is made explicit with the override keyword. This helps you release new versions of your code; changes to the base class will not break existing code in the derived classes. The requirement to use the keyword override helps prevent that problem.

Here's how: assume for a moment that the Window base class of the previous example was written by Company A. Suppose also that the ListBox and RadioButton classes were written by programmers from Company B using a purchased copy of the Company A Window class as a base. The programmers in Company B have little or no control over the design of the Window class, including future changes that Company A might choose to make.

Now suppose that one of the programmers for Company B decides to add a Sort( ) method to ListBox:

public class ListBox : Window {    public virtual void Sort( ) {...} }

This presents no problems until Company A, the author of Window, releases Version 2 of its Window class, and it turns out that the programmers in Company A have also added a Sort( ) method to their public class Window:

public class Window {    // ...    public virtual void Sort( ) {...} }

In other object-oriented languages (such as C++), the new virtual Sort( ) method in Window would now act as a base method for the virtual Sort( ) method in ListBox. The compiler would call the Sort( ) method in ListBox when you intend to call the Sort( ) in Window. In Java, if the Sort( ) in Window has a different return type, the class loader would consider the Sort( ) in ListBox to be an invalid override and would fail to load.

C# prevents this confusion. In C#, a virtual function is always considered to be the root of virtual dispatch; that is, once C# finds a virtual method, it looks no further up the inheritance hierarchy. If a new virtual Sort( ) function is introduced into Window, the runtime behavior of ListBox is unchanged.

When ListBox is compiled again, however, the compiler generates a warning:

...\class1.cs(54,24): warning CS0114: 'ListBox.Sort( )' hides  inherited member 'Window.Sort( )'.  To make the current member override that implementation,  add the override keyword. Otherwise add the new keyword.

To remove the warning, the programmer must indicate what he intends. He can mark the ListBox Sort( ) method new, to indicate that it is not an override of the virtual method in Window:

public class ListBox : Window {    public new virtual void Sort( ) {...}

This action removes the warning. If, on the other hand, the programmer does want to override the method in Window, he need only use the override keyword to make that intention explicit:

public class ListBox : Window {    public override void Sort( ) {...}

To avoid this warning, it might be tempting to add the keyword new to all your virtual methods. This is a bad idea. When new appears in the code, it ought to document the versioning of code. It points a potential client to the base class to see what it is that you are not overriding. Using new scattershot undermines this documentation. Further, the warning exists to help identify a real issue.