(From an article I originally wrote in 2004)

Part 1

Introduction

This series covers advanced topics and is not intended to be an exhaustive treatment of the subjects discussed. My intention is to provide the reader with a better understanding of the Overloads, Overrides, and Shadows keywords. Where necessary, I will refer the reader to other sources for more details. If you’re a VB.NET programmer who writes software components intended for use by other programmers or applications that can be extended by other programmers, or if you use third party components or extend components written by others, you will certainly want to become more familiar with these keywords as they will allow you to leverage more of the power and flexibility built into an object oriented language like VB.NET.

Note: This series is applicable to VB.NET programmers only. C# provides it’s own flavor of support for member hiding (shadowing), virtual functions, and overloading. And since there are significant differences in the C# implementation, here we’re discussing only VB.NET.

Also, in these articles I use the word “method” to mean any procedure in VB.NET (i.e., Subs, Functions, and Property procedures).

Those three keywords Overloads, Overrides, and Shadows, are not easy keywords to understand. For some, there is a fog of confusion that surrounds them and many programmers have to wrestle with object oriented design concepts, and the connection those concepts have to these keywords, before that fog clears. MSDN offers some explanation in an online help sort of way, but programmers are a practical bunch and when they need an explanation, they want it to be applicable to how it affects them in their coding activities.

In this multi-part series I’m going to try to lift that fog, hopefully clearing it completely away so that you have a better understanding of the similarities and differences between these three keywords and how they affect you as a programmer.

My assumptions about you.

I assume you have a basic understanding of object oriented program design and construction. At the very least, you should know what Inheritance is and how it is implemented in a program. You should know what it means to derive a class and you should understand the concept of a base class. If you don’t have any idea what all this means, don’t sweat it, just read up on the subject at the following link and then come back here: Inheritance.

Why should you read this series?

More than anything else, the uses of these three keywords are impacted by design decisions. That’s right, when you design a base class or when you derive a class, you need to keep aware of the concepts of overloading, overriding, and shadowing (in addition to other design concepts) to allow you or other programmers to make the most out of that class during the construction of a program.

Now, if you’re a programmer who is not responsible for the design of an application, and your responsibility is to simply follow the instructions of your supervisor/manager, you may be asking yourself: If these keywords have to do with the design of a program, why do I need to understand them?

The answer is simple. Every time you write a line of code you affect the design of your application. You need to understand these keywords because understanding them allows you to code in compliance with and in support of the design. Additionally, your understanding of these keywords allows you to take advantage of the design decisions made by the architects of the software components you use. Components to which you may not have source code access. Also, as a .NET object oriented programmer, it is almost a certainty that you will find yourself deriving your own classes, where the impact of these keywords will affect how you code those classes. (Imagine how tedious it would be if you were to create all your forms without inheriting from the form class).

This means you will know if and when to use these keywords and your code will be more elegant, efficient, and professional.

On the other hand, if you don’t understand these keywords you will avoid using them, or worse, use them incorrectly. Your code will not be as efficient and as elegant as it could be. When you derive classes from third party components, you may find that the code in an application that uses your class behaves in an unexpected manner because the designer of the base class made conflicting changes in subsequent versions of his class. To other experienced programmers, your avoidance of these keywords will be obvious. To the end users of your components, you may seem a novice in your field. Eventually, this will mark you as an amateur among your peers, and we don’t want that!

Another interesting fact is if you never code derived classes and you never code base classes, you would never have to worry about using these keywords. In an object-oriented language like VB.NET, that scenario is very unlikely. So let’s learn about them.

Summary

In this installment I discussed why you would want to learn more about the Overloads, Overrides, and Shadows keywords.

In the next installment I’ll go into more detail and discuss the Overloads keyword, describing how it works and some things you should know about when and how to use it. I’ll see you there.