Versioning with New and Override In Visual Basic 2005, the programmer's decision to override an overridable method is made explicit with the overrides keyword. This helps with versioning . 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 Inherits Window Public Overridable Sub Sort( ) '... End Sub 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 Overridable Sub Sort( ) '... End Sub In other object-oriented languages (such as C++), the new overridable Sort method in Window would now act as a base method for the 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 had a different return type, the class loader would consider the Sort in ListBox to be an invalid override and would fail to load. Visual Basic 2005 prevents this confusion. In Visual Basic 2005, an overridable function is always considered to be the root of dispatch; that is, once Visual Basic 2005 finds an overridable method, it looks no further up the inheritance hierarchy. If a new overridable Sort function is introduced into Window, the runtime behavior of ListBox is unchanged. When ListBox is compiled again, however, the compiler generates a warning: Module1.vb(31) : warning BC40005: sub 'Sort' shadows an overridable method in a base class. To override the base method, this method must be declared 'Overrides'. To remove the warning, the programmer must indicate what she intends. She can mark the ListBox Sort method Shadows, to indicate that it is not an override of the Sort method in Window: Public Class ListBox Inherits Window Public Shadows Sub Sort( ) '... End Sub 'Sort 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: Public Class ListBox Inherits Window Public Overrides Sub Sort( ) '... End Sub 'Sort To avoid this warning, it might be tempting to add the keyword Shadows to all your overridable methods. This is a bad idea. When Shadows 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 Shadows scattershot undermines this documentation. Further, the warning exists to help identify a real issue. |