In VB.NET, everything is an object and the basis of an object is a class. You might see a definition of a class like this: "Classes are templates used for defining new types."
A template is just a word for code that is designed to be copied and used to create an instance of the class. In the definition above, it's the program code for the class. But type is a more difficult word because it's used a lot but it's not precisely defined. Most often, you see it defined by example: "Integer and Char are examples of types." In the definition above, it's the same thing as "object". So, since type is so poorly defined in software, let's go back to the dictionary definition: "Things sharing a set of characteristics." What characteristics? Properties, methods, events, fields, and constants -- all those other things that do have clear definitions. All Integer types share certain characteristics. And if you create a new "type" - that is, a class - in your program, you define the characteristics that will be shared.
So a class is a template for a type. Here's one written in VB.NET:
Public Class Contact
End Class
There's not much to it. In fact, the only "characteristic" of this class is the name. But it is a valid class. You can code ...
Dim theContact As New Contact
... somewhere else in the project and it works. But a real class has much more and in particular, it usually defines properties, methods and often events. You can think of a property as something is has and a method as something it does. "Contact" - in this case - is someone you met that you want to remember; like in an address book. So some of the properties that the class could define are:
ContactName
ContactDate
This class could be improved a lot by adding things like validity checking and more specific details. (For example, first and last name?) Methods, such as "UpdateName" and events, such as "NameUpdated" could also be coded and added, but coding these right now would take us in a different direction and this article is more about inheritance.
Here's an improved version of the Contact class where the two properties that apply to any contact have been added.
Public Class Contact
Public Sub New(ByVal cn As String, ByVal cd As Date)
ContactName = cn
ContactDate = cd
End Sub
Public Property ContactName As String
Public Property ContactDate As Date
End Class
A New subroutine has also been added to initialize the values of the properties. "New" is the actual name of the subroutine and this subroutine is called automatically whenever the class is instantiated (a copy made for this program). The class is instantiated like this:
Dim theContact As New Contact(
"George of the Jungle", #10/1/1912#
)
One characteristic that is not a property of the class above is "type of contact" Is it a "professional" or "personal" contact? Maybe even something more specific like "home" or "entertainment". If a contact is "personal", then you might want also want to have a property like, "IntroducedBy". If it's "professional", then you might want one like, "BusinessName". They're both "contacts", but the details are different.
This is where inheritance comes in. Although there are some details that any contact will have, others should be unique. In most cases, the best way to add those unique details is to create a new class and inherit the characteristics of the more general class while adding the details required by the new class. In pictures, a professional or personal contact class could be based on the base Contact class like this:
--------
Click Here to display the illustration
--------
Add an Inherits statement immediately below the class statement to inherit. In our case, since the base class requires a name and date, the inherited derived class also requires the same two values. ("Like parent, like child." as the saying goes.) But since this new derived class also includes another property, we can require that in the New subroutine for this derived class.
Public Class ProfessionalContact
Inherits Contact
Public Sub New(
ByVal cn As String,
ByVal cd As Date,
ByVal bn As String
)
MyBase.New(cn, cd)
BusinessName = bn
End Sub
Public Property BusinessName As String
End Class
MyBase.New simply passes on the two inherited properties. The new BusinessName property is handled in this class. The MyBase.New statement must be the first one after the Sub New statement. (If you do anything else, the compiler will remind you.) But, and this is the important concept, code that calls this new class can't tell the difference between inherited properties and those added by the derived class.
Dim theContact As New ProfessionalContact(
"George of the Jungle",
#10/1/1912#,
"Vine Hangers, Inc."
)
Console.WriteLine(
theContact.ContactName & " -- " &
theContact.ContactDate & " -- " &
theContact.BusinessName
)
The next concept to learn after simple inheritance is probably the idea of overloading. Microsoft's definition is pretty good:
Overloading a procedure means defining it in multiple versions, using the same name but different parameter lists.
Using the example above, suppose some ProfessionalContact object just didn't have a business name immediately available? (How often have you heard it, "The computer won't let me enter it this way!") You might want to define two New procedures, one with and one without a business name. A key concept of inheritance is that the compiler can figure out which procedure you intend, simply by picking the one that matches the parameter list you used.
So, you can add another New subroutine to the ProfessionalContact class, right below the first one, like this:
Public Sub New(
ByVal cn As String,
ByVal cd As Date
)
MyBase.New(cn, cd)
End Sub
But this makes it almost identical to the Contact base class. Almost, except that the Contact base class doesn't have a BusinessName property.
Here's one way that this New subroutine with just two parameters might be used. Suppose that a BusinessName can be either a string (like "Vine Hangers, Inc." used above) or an integer code (like 123 where that number can be converted to the full name). If you use a dictionary object or a database, it could be more efficient to store an integer code rather than the full name of a business. You can accomplish this by both inheriting the ProfessionalContact class and overloading the property in a new class that I have named CodedProfessionalContact. (Properties can be overloaded as well as methods!)
Public Class CodedProfessionalContact
Inherits ProfessionalContact
Public Sub New(
ByVal cn As String,
ByVal cd As Date,
bn As Integer
)
MyBase.New(cn, cd)
BusinessName = bn
End Sub
Public Overloads Property BusinessName As Integer
End Class
Note that My.Base.New above takes just two parameters, not three, so the ProfessionalContact class that is inherited has to have this overloaded New subroutine available. And, again, the code that uses this class doesn't know how the properties are being handled.
Dim theContact As New CodedProfessionalContact(
"George of the Jungle",
#10/1/1912#,
123
)
Console.WriteLine(
theContact.ContactName & " -- " &
theContact.ContactDate & " -- " &
theContact.BusinessName
)
We now have three classes where each one inherits from a parent class. This kind of thing can be complex to visualize, so Visual Studio provides a Class Designer tool that makes it easy. Here's the class structure that we have created.
--------
Click Here to display the illustration
--------
About Visual Basic also features a much more complete article about this tool: