The Abstract Base Class
If you look up "abstract base class" at Microsoft, you will get hits on C# and C++ pages that may not help you a lot if you're looking for help in VB.NET. The problem here is that VB doesn't use the same keywords. In VB.NET, these classes are formally called "MustInherit" classes. But the concept - and the words that are usually used to describe them - originated in C. It's a tradition we're stuck with and this article isn't going to change it.
About Visual Basic features several other articles that touch on this same topic. An article was written years ago when this language feature was a lot less familiar to VB.NET programmers: MustInherit and NotInheritable in VB.NET. That two part article is still valid today and you might want to read it for a different approach to the topic. Part 8 of a series on GDI+ graphics explains abstract base classes in the context of GDI+: GDI+ Graphics in Visual Basic.
Most articles about this subject start with the definition of an abstract base class, but I'm going to start by telling you why it's useful. We'll get to the definition after that.
If you're writing a single, standalone program, you might never see a need for an abstract base class. It's something that is really only useful in systems of programs; and specifically in systems where different programmers may update the same code base over years. In this kind of situation, the big picture can get lost and programmers may not know exactly how to write a new part of the system or upgrade an old part.
Details can be forgotten.
For example, suppose you are designing a new accounting system. (I know ... that's very unlikely today. But go with me on this.) A primary object in the system will undoubtedly be an "Account" object. As the original designer, there will be lots of things that you won't know about how the Account object may be used in the future. The "home planet" of the account may become a required field, for example. But, in order for the system you are designing to work correctly, you do know some things that must be done.
For example, a new account number must be created and checked to make sure it's unique. Version 1.0 of the system will have a way to do that but by the time Version 666 of the system is being coded, things may have changed a lot. (The Internet is moving from IPV4 to IPV6 to expand the number of unique "numbers" available.) So if you make the code that creates and checks an account number a fixed part of the system, future programmers may have real trouble.
The solution is to write the code in two parts. A "base" class that specifies what must be done and a "derived" class that does it. Version 1.0 comes with a derived class, but it's easy to swap it out for a different one.
An "interface" is a related concept. The difference is that an interface defines only what must be done and doesn't actually contain any code. An abstract class may define some of the code but not all of it and must be inherited by a derived class where the rest of the code is. You use an interface where the only thing you want to define is the set of elements (events, properties, methods) that have to be coded.
A much more complete article about interfaces can be found here: Interface Definitions and Why You Should Care.
So, here's the promised definition:
An abstract class is a class that cannot be instantiated, but must be inherited from.
The code will look like this:
The VB.NET compiler enforces the "MustInherit" requirement with an error if you try to declare the class as New.
"New cannot be used on a class that is declared MustInherit."
But this doesn't mean that you have to code a class that is declared MustInherit; only that you can't instantiate it. To use the base class, you must instantiate a derived class.
Unlike Interfaces, an abstract class gives you three choices in controlling the code that inherits the base class.
-> The default is that elements cannot be overridden in a derived class; the derived class must use the member exactly as defined in the abstract class. This is what you get if you define a member in the abstract class with no special keywords.
-> Code that inherits the class can choose whether to override properties and methods if Overridable is in the definition in the base class. The code in the derived class must then use the Overrides keyword.
-> The MustOverride keyword in an abstract class tells the derived class that an element, well ..., must be overridden. One syntax difference is that when an element is declared this way, it doesn't have an End Sub or End Function statement. But the signature (parameters that must be passed) is specified so the sub that provides the override code in the derived class must match them. Elements declared this way are called Abstract members.
You can see more examples in the article Overloads Versus Overrides.
About Visual Basic features several other articles that touch on this same topic. An article was written years ago when this language feature was a lot less familiar to VB.NET programmers: MustInherit and NotInheritable in VB.NET. That two part article is still valid today and you might want to read it for a different approach to the topic. Part 8 of a series on GDI+ graphics explains abstract base classes in the context of GDI+: GDI+ Graphics in Visual Basic.
Most articles about this subject start with the definition of an abstract base class, but I'm going to start by telling you why it's useful. We'll get to the definition after that.
If you're writing a single, standalone program, you might never see a need for an abstract base class. It's something that is really only useful in systems of programs; and specifically in systems where different programmers may update the same code base over years. In this kind of situation, the big picture can get lost and programmers may not know exactly how to write a new part of the system or upgrade an old part.
Details can be forgotten.
For example, suppose you are designing a new accounting system. (I know ... that's very unlikely today. But go with me on this.) A primary object in the system will undoubtedly be an "Account" object. As the original designer, there will be lots of things that you won't know about how the Account object may be used in the future. The "home planet" of the account may become a required field, for example. But, in order for the system you are designing to work correctly, you do know some things that must be done.
For example, a new account number must be created and checked to make sure it's unique. Version 1.0 of the system will have a way to do that but by the time Version 666 of the system is being coded, things may have changed a lot. (The Internet is moving from IPV4 to IPV6 to expand the number of unique "numbers" available.) So if you make the code that creates and checks an account number a fixed part of the system, future programmers may have real trouble.
The solution is to write the code in two parts. A "base" class that specifies what must be done and a "derived" class that does it. Version 1.0 comes with a derived class, but it's easy to swap it out for a different one.
An "interface" is a related concept. The difference is that an interface defines only what must be done and doesn't actually contain any code. An abstract class may define some of the code but not all of it and must be inherited by a derived class where the rest of the code is. You use an interface where the only thing you want to define is the set of elements (events, properties, methods) that have to be coded.
A much more complete article about interfaces can be found here: Interface Definitions and Why You Should Care.
So, here's the promised definition:
An abstract class is a class that cannot be instantiated, but must be inherited from.
The code will look like this:
Public MustInherit Class baseClassPublic Property theAbstractClassProperty As StringPublic Event theAbstractClassEvent(ByVal eventParm As String)Public Sub theAbstractMethod(ByVal eventParm As String)' StatementsEnd SubEnd ClassThe VB.NET compiler enforces the "MustInherit" requirement with an error if you try to declare the class as New.
"New cannot be used on a class that is declared MustInherit."
But this doesn't mean that you have to code a class that is declared MustInherit; only that you can't instantiate it. To use the base class, you must instantiate a derived class.
Dim theDerivedClass As New derivedClass...Class derivedClassInherits baseClass' StatementsEnd ClassUnlike Interfaces, an abstract class gives you three choices in controlling the code that inherits the base class.
-> The default is that elements cannot be overridden in a derived class; the derived class must use the member exactly as defined in the abstract class. This is what you get if you define a member in the abstract class with no special keywords.
-> Code that inherits the class can choose whether to override properties and methods if Overridable is in the definition in the base class. The code in the derived class must then use the Overrides keyword.
-> The MustOverride keyword in an abstract class tells the derived class that an element, well ..., must be overridden. One syntax difference is that when an element is declared this way, it doesn't have an End Sub or End Function statement. But the signature (parameters that must be passed) is specified so the sub that provides the override code in the derived class must match them. Elements declared this way are called Abstract members.
Public MustOverride Sub theAbstractMethod(ByVal eventParm As String)' StatementsYou can see more examples in the article Overloads Versus Overrides.
Source...