| A class that cannot be instantiated and must be inherited is referred to generically as a virtual abstract class. Such classes in Visual Basic .NET are indicated by the presence of the MustInherit class modifier. Virtual abstract classes were defined in C++ before COM interfaces. Virtual abstract classes are the closest thing to pure COM interfaces. When you define a class with the MustInherit modifier, you are communicating to consumers that all child classes of the virtual abstract class must implement all of the members marked with the MustOverride modifier in the parent class. If a child only implements some of the virtual abstract members in the parent, the child also is virtual and abstract. MustInherit classes have at least one MustOverride member. Methods and property methods that have the MustOverride modifier are referred to as virtual abstract methods. In addition to the MustOverride directive, virtual abstract members have no method body. (Method properties have no property body either.) A MustInherit class where all members are MustOverride members is a pretty good approximation of an interface. Chapter 7 defines a virtual abstract Light class that is part of a traffic signal class. Each of the three traffic lamps must override and provide an implementation of the Brush property used to constrain the color of the lamp for each traffic signal. The subsection that follows demonstrates another example for aircraft. Virtual Abstract Class Example Planes in the U.S. have a call sign designator that begins with an N-prefix. For example, N633DV is a call sign on a Cessna 172 parked at Austin-Bergstrom. If we were representing planes, perhaps for an inventory-tracking application for a reseller, we would probably want to ensure that the tail number is a member of our plane class. To ensure that all aircraft that needed a tail number had one, we could define an interface or an abstract virtual (MustInherit) class that had a TailNumber property. Listing 10.4 demonstrates using an interface and Listing 10.5 demonstrates using an abstract class. Listing 10.4 Using an Interface to describe planes as having a required tail number. 1: Namespace InterfacePlane 2: Public Interface Plane 3: Property TailNumber() As String 4: End Interface 5: 6: Public Class SingleEngineLand 7: Implements Plane 8: 9: Private FTailNumber As String 10: Public Property TailNumber() As String Implements Plane.TailNumber 11: Get 12: Return FTailNumber 13: End Get 14: Set(ByVal Value As String) 15: FTailNumber = Value 16: End Set 17: End Property 18: End Class 19: 20: End Namespace Line 1 begins a new namespace, InterfacePlane. The example plane.sln defines the name Plane name twice; in the example, separating the same name , Plane, with a namespace is a notational convenience. Lines 2 through 4 define the Plane interface as having a TailNumber property. Line 7 indicates that the SingleEngineLand category of plane implements the Plane interface, and line 10 satisfies the contract between interface and class by implementing the Plane.TailNumber property. (The Implements clause is tagged to the end of the property statement on line 10.) Listing 10.5 Using an abstract virtual class to describe planes as having a required tail number. 1: Namespace ClassPlane 2: 3: Public MustInherit Class Plane 4: Public MustOverride Property TailNumber() As String 5: End Class 6: 7: Public Class SingleEngineLand 8: Inherits Plane 9: Private FTailNumber As String 10: 11: Public Overrides Property TailNumber() As String 12: Get 13: Return FTailNumber 14: End Get 15: Set(ByVal Value As String) 16: FTailNumber = Value 17: End Set 18: End Property 19: 20: End Class 21: 22: End Namespace Listing 10.5 employs the MustInherit modifier on line 3 to define an abstract Plane class. Line 8 indicates that SingleEngineLand inherits from Plane, and the contract between abstract class and child class is fulfilled by the Overrides Property statement that defines a TailNumber property. The InterfacePlane.SingleEngineLand and ClassPlane.SingleEngineLand interface and class are very similar in a technical sense. There are a few pragmatic considerations to help you choose between using an interface or an abstract class: -
Child classes that inherit from abstract classes get a copy of the defined methods, properties, and events and have to define the abstract members. If you think you will be creating multiple versions of a class, use abstract classes. Revisions in the abstract base class will be inherited by child classes. -
If the capabilities will be useful across disparate kinds of classes, use an interface. Abstract classes are generally used for classes that are closely related . For example, a Skyhawk is a kind of plane; hence we are talking about an inheritance relationship. Alternatively, we might implement a throttle interface in a plane and a car. A throttle is not a kind of car or plane, and both planes and cars would probably implement throttles but differently. -
Think of an interface as an attachment to a class that allows you to access a concise set of capabilities externally, like a portal. Think of a class as being a fundamental identifier. For example, a home receiver and car radio are kinds of radios, clearly defining a class relationship. The ability to attenuate volume can be applied to a microphone, megaphone, or radio; attenuating volume describes concise capability, and thus can serve as an interface. -
If you need partial implementation and some abstract aspects, use an abstract class and inheritance. Interfaces provide no implementation. C++ and Object Pascal programmers have been aware of the absence of inheritance and abstract classes in VB (if they thought of VB at all). If you have only programmed in VB, you may be comfortable with interfaces, but from now on, when you want to inherit partial implementation and some abstraction, bear in mind that abstract classes are perfect. | 
