Polymorphism in C# - Versioning with new and override
(Page 2 of 6 )
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 theoverridekeyword helps prevent that problem.
Here’s how: assume for a moment that Company A wrote theWindowbase class in Example 11-2. Suppose also that theListBoxandRadioButtonclasses 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 aSort()method toListBox:
public class ListBox : Window
{
public virtual void Sort() {...}
}
This presents no problems until Company A, the author ofWindow, releases Version 2 of itsWindowclass, and the programmers in Company A also add aSort()method to their public classWindow:
public class Window
{
// ...
public virtual void Sort() {...}
}
In other object-oriented languages (such as C++), the new virtualSort()method inWindow would now act as a base virtual method for theSort()method inListBox, which is not what the developer ofListBoxintended.
C# prevents this confusion. In C#, avirtualfunction 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 virtualSort()function is introduced intoWindow, the runtime behavior of ListBoxis unchanged.
WhenListBoxis 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.
Never ignore warnings. Treat them as errors until you have satisfied yourself that you understand the warning and that it is not only innocuous but that there is nothing you can do to eliminate the warning. Your goal, (almost) always, is to compile warning-free code.
To remove the warning, the programmer must indicate what she intends.* She can mark theListBox Sort()methodnew to indicate that it is not an override of the virtual method in Window:
public class ListBox : Window
{
public new virtual void Sort() {...}
*In standard English, one uses “he” when the pronoun might refer either to a male or a female. Nonetheless, this assumption has such profound cultural implications, especially in the male-dominated programming profession, that I will use the term “she” for the unknown programmer from time to time. I apologize if this causes you to falter a bit when reading; consider it an opportunity to reflect on the linguistic implications of a patriarchal society.
This action removes the warning. If, on the other hand, the programmer does want to override the method in Window, she need only use theoverride keyword to make that intention explicit:
public class ListBox : Window
{
public override void Sort() {...}
To avoid this warning, it might be tempting to add thenewkeyword to all your virtual methods. This is a bad idea. Whennewappears 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 intentionally not overriding. Usingnewscattershot undermines this documentation and reduces the utility of a warning that exists to help identify a real issue.
If the programmer now creates any new classes that derive fromListBox, those derived classes will inherit theSort()method fromListBox, not from the baseWindowclass.
Next: Abstract Classes >>
More C# Articles
More By O'Reilly Media
|
This article is excerpted from chapter 11 of Learning C# 2005, Second Edition, written by Jesse Liberty and Brian MacDonald (O'Reilly, 2006; ISBN: 0596102097). Check it out today at your favorite bookstore. Buy this book now.
|
|