18.18. The Root of All Classes: Object


All Visual Basic 2005 classes, of any type, ultimately derive from System.Object. Interestingly, this includes value types!

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.


A base class is the immediate "parent" of a derived class. A derived class can be the base to further derived classes, creating an inheritance "tree" or hierarchy. A root class is the top-most class in an inheritance hierarchy. In Visual Basic 2005, the root class is Object. The nomenclature is a bit confusing until you imagine an upside-down tree, with the root on top and the derived classes below. Thus, the base class is considered to be "above" the derived class.

Object provides a number of methods that subclasses can and do override. These include Equals to determine if two objects are the same; GetType, which returns the type of the object; and ToString, which returns a string to represent the current object. Table 18-3 summarizes the methods of Object.

Table 18-3. The Object class

Method

What it does

Equals

Evaluates whether two objects are equivalent

GetHashCode

Allows objects to provide their own hash function for use in collections

GetType

Provides access to the type object

ToString

Provides a string representation of the object

Finalize

Cleans up nonmemory resources; implemented by a destructor

MemberwiseClone

Creates copies of the object; should never be implemented by your type

ReferenceEquals

Evaluates whether two objects refer to the same instance




Programming Visual Basic 2005
Programming Visual Basic 2005
ISBN: 0596009496
EAN: 2147483647
Year: 2006
Pages: 162
Authors: Jesse Liberty

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net