Click here to Skip to main content
12,701,573 members (34,149 online)
Click here to Skip to main content
Add your own
alternative version


32 bookmarked

The Dark Shadow of Overrides

, 15 Feb 2007 CPOL
Rate this:
Please Sign up or sign in to vote.
This article hopefully will assist you in minimizing your learning curve.


As a new VB developer, I am not sure you have encountered an application leveraging some of the fundamentals of the VB.NET implementation. Specifically, the difference between the keywords Shadows and Overrides. This article, hopefully, will assist you in minimizing your learning curve.


Before the .NET craze, there was a strong following to Visual Basic in the business world, and C++ in the more academic communities. The interesting core difference between these two languages was the fundamental design principle that molded their development. C++'s guiding principle was "Keep the runtime small, and assume a genius developer is behind the keyboard". Visual Basic's core was "Rapid development, assuming average developers". At this point, I have started the ever-lasting VB vs. C flame war. Please hold off for a moment before casting a fireball spell on me. The design goals of the languages were different, not bad - just different. Due to these design principles, VB had a fairly large set of runtime functionality; therefore, strings were native in VB and pointers were discouraged. In C++, in contrast, strings were external while pointers were first class objects. As a result, VB of old did not support many of the object oriented principles as C++, specifically: inheritance and multithreading (Visual Basic 2007). VB.NET has reconciled that drawback, and thus we have the C#, VB.NET religious wars.


Public Class Invoice 

    Public Sub ProcessInvoice() 
    End Sub 

End Class 

Public Class TimeMaterials 
    Inherits Invoice 

    Public Overloads Sub ProcessInvoice(Invoice as Int) 
    End Sub 
End Class

VB.NET with its new features needed new nomenclature. However, before we can discuss the solution, we should understand what challenges are they trying to solve. Assume I have an object, Invoice, which has a function ProcessInvoice. Moreover, assume that I wish to derive a child from Invoice, TimeMaterialsInvoice, which also has a ProcessInvoice function, review Snippet 1. Elsewhere in code, I have a snippet which looks as follows:

Dim bill as Invoice = new TimeMaterialsInvoice()


As a brilliant young complier, what am I to do? Of course, I widen the TimeMaterialsInvoice object bill to simulate the Invoice class. However, I know there are two implementations of ProcessInvoice, and I know that this code has the capability to access both of them. So as a computer, this ambiguity confounds me; therefore, I must hack an error loogie on the user! And the user must solve my problem.


Ultimately, there are only a handful of solutions: the user wishes to call the base class method, the user wishes to have the freedom to call either function, or the user wishes to call the instantiated version. First, if the user wishes to call the Invoice function, then the TimeMaterialsInvoice code should have used the Shadows keyword. Thus, the TimeMaterialsInvoice code will not be invoked. An alternative approach, although it will generate warnings, is to remove all modifiers from both functions because the VB.NET compiler assumes the Shadows keyword applies to the TimeMaterialsInvoice method.

If the consumer wants to call the Invoice function some of the time and TimeMaterialsInvoice method other times, it can be achieved with function signatures; in other words, based on the best argument fit. The complier would use an educated guess to choose the correct implementation. Unfortunately, since, both versions of ProcessInvoice have the same signature, in this case, this is not an option (see Appendix).

If the consumer wishes to invoke the TimeMaterialsInvoice method, either the client code or the base class must be aware of the child class. Assuming the client code is aware of the child definition, then the solution to invoke the child ProcessInvoice() is simple; change the definition of the object to the following:

Dim bill as TimeMaterialsInvoice = new TimeMaterialsInvoice() 

However, this may not be desirable because this forces the client to use the single TimeMaterialsInvoice implementation. It is generally a best practice to code against the most generic interface or base class that defines the desired response. Therefore, the client code should look as follows:

Dim bill as Invoice = new TimeMaterialsInvoice()

Note: the more generic definition of our object. In order to use this syntax, and have the effect of calling the TimeMaterialsInvoice version of ProcessInvoice, we need to add the keywords Overridable and Overrides:

Public Class Invoice 

    Public Overridable Sub ProcessInvoice() 
    End Sub 
End Class 

Public Class TimeMaterials 
    Inherits Invoice 

    Public Overrides Sub ProcessInvoice(Invoice as Int) 
    End Sub 
End Class

The keyword Overridable in the base class gives the complier permission to replace the said function with a child implementation. Similarly, the keyword Overrides informs the complier this function will be overriding the original function of the same name.

Conceptually, there is no difference between Shadows and Overrides, as they both alter the invocation tree; however, they are fundamentally different in their solution. Recall our example:

Dim bill as Invoice = new TimeMaterialsInvoice()

Bill's type is of Invoice, while its implementation is of TimeMaterialsInvoice. In general, Shadows assumes the function associated with the type is invoked, while Overrides assumes the object implementation is executed.

Appendix – Other language implementations

Ironically, all of these same challenges exist in C#, Java, and any other OOP programming language.











Note: Regarding Overloads

The keyword Overloads, although is used during the class design time, enables a very different syntactical result, when compared to Shadows or Overrides. Formally, overloading is creating many definitions with the same name; therefore, to tell them apart, the compiler requires them to have different method signatures. The VB.NET complier, for reasons of clarity, decided to require the Overloads keyword, as in Snippet 2, to expose both implementations to the class consumer. A real-life example of this would be the DateTime.ToString function. An alternative overloaded option is DateTime.ToString(String), where the String argument is a formatting option. If the consumer of DateTime wishes for the defaults, the first implementation is elected. In contrast, if the consumer wishes to make his formatting explicit, he could choose the second by submitting a String argument.

Public Class Invoice 

    Public Sub ProcessInvoice() 
    End Sub 

End Class 

Public Class TimeMaterials 
    Inherits Invoice 

    Public Overloads Sub ProcessInvoice(Invoice as Int) 
    End Sub 
End Class

Revision log


  • Posted article.


  • Altered C# cross references, based on Mr. Menski's suggestions.
  • Made hyperlinks functional.



This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Jason McBurney
United States United States
Berkeley Grad (B.A. Computer Science) With MBA

You may also be interested in...

Comments and Discussions

GeneralNotes for MBAs. Pin
lafleon15-Feb-07 11:58
memberlafleon15-Feb-07 11:58 
GeneralRe: Notes for MBAs. Pin
Jason McBurney16-Feb-07 5:21
memberJason McBurney16-Feb-07 5:21 
JokeGreat article, but... Pin
blyman12-Feb-07 4:04
memberblyman12-Feb-07 4:04 
GeneralRe: Great article, but... Pin
Jason McBurney13-Feb-07 6:56
memberJason McBurney13-Feb-07 6:56 
GeneralError Lugi Pin
scorpydude11-Feb-07 15:55
memberscorpydude11-Feb-07 15:55 
GeneralKeywords in C# Pin
Pahan Menski9-Feb-07 4:56
memberPahan Menski9-Feb-07 4:56 
GeneralRe: Keywords in C# Pin
Jason McBurney13-Feb-07 6:55
memberJason McBurney13-Feb-07 6:55 
This is interesting, when testing the new keyword in c# - the IL looked like it compiled into a shadowed funciton. I will do some more research.

Sorry for the confusion.

You can only be young once. But you can always be immature.
- Dave Barry

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.170118.1 | Last Updated 15 Feb 2007
Article Copyright 2007 by Jason McBurney
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid