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.
Creating Polymorphic Types
Because a ListBox is a Window and a Button is a Window, you 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 ListBoxes 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. You implement this polymorphism with polymorphic methods.
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 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(), and the method will be invoked polymorphically. 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.
Versioning with new and override
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 override keyword helps prevent that problem.
Here's how: assume for a moment that Company A wrote the Window base class of the previous example. 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.
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:
To remove the warning, the programmer must indicate what she intends. She can mark the ListBox Sort() method new to indicate that it is not an override of the virtual method in Window:
This action removes the warning. If, on the other hand, the programmer does want to override the method in Window, she need only use the override keyword to make that intention explicit:
DAY 1 MICROSOFT DOT NET FRAME WORK
DAY 2 MICROSOFT DOT NET BASE CLASS LIBRARY
DAY 3 MICROSOFT DOT NET CLASSES AND STRECTURES
DAY 4 METHODS IN FRAME WORK
DAY 5 INPUT VALIDATIONS IN DOT NET PART ONE
DAY 6 INPUT VALIDATIONS IN DOT NET PART TWO
DAY 7 DATA TYPES IN DOT NET
DAY 8 DATA TYPES IN DOT NET PART TWO
DAY 9 IMPLEMENTING PROPERTIES IN DOT NET
DAY 10 DELEGATES AND EVENTS
DAY 11 OOPS INTRODUCTION
DAY 12 POLYMORPHISM
DAY 13 INHERITANCE AND POLYMORPHISM
DAY 14 EBUGGING TOOLS IN DOT NET
DAY 15 DEBUG AND TRACE IN CLASSES
DAY 16 UNIT TEST PLAN
DAY 17 EXCEPTIONS IN VISUAL STUDIO
DAY 19 ADO.NET INTRODUCTION
DAY 20 DATA ACCESSING IN DOT NET
DAY 21 DATA BASE OBJECTS