Polymorphism, as you may know, is a feature of object-oriented design and programming that enables
you to use a single object class in more than one way.
You typically apply this concept to general object types, such as Person, Animal, File, or
Vehicle. Such general types could represent very disparate objects. A Vehicle object, for example,
might represent either an automobile, a spaceship, an airplane, or an ox cart, to name just a few
Each specific object type then usually has at least two subsets of features: features that apply
to all objects instantiated from that class (all Vehicles, for instance, have properties such as
Speed and Maximum Speed, and methods such as Travel); and, on the other hand, features that apply only
to certain types of objects in that class (such as NumberOfWings, MaximumAltitude, MinAnimalsNeededToMove,
and so forth). An additional consideration for the common features would be the fact that the
same methods and properties might need to behave differently for different types of objects (the
Travel method would behave differently for different types of objects).
If you want to provide general object classes along with more specific implementations of those
classes in your COM component, you have several hoices in VB:
Add all the properties and methods to a single class. By doing this, any object
instantiated from the Vehicle class would have a NumberOfWings property, even if the
particular object in question were a school bus. In addition, a Startup method might have
to behave very differently, depending on whether the object in question were a spaceship or
an ox cart. You would have to put special logic in that method to determine which Startup
actions to take, based on the type of object.
Create a completely separate class specific to each type of object. These object classes
would share a lot of members in common, but they would be completely separate from each
other. You would have a SchoolBus class, for example, that had the generic object members
such as the Speed property and the Travel method. Likewise, all your other Vehicle-type
classes would have these generic object members. The Schoolbus class, however, would have a
MaximumChildren property and a DisplayStopSign method. You would write separate routines
in each class for all common properties and methods.
Use the concept of an Interface class that will define (but will not implement) common
properties and methods for the more specific classes. Create separate classes that then
implement each specific type of object that you will need and that use the Interface class
to specify common functionality.
The Interface class provides an abstract definition for the properties and methods of a generic type
of object. It does not, however, provide that behavior. Each specific object class that implements
the Interface class must actually provide code for each of the methods and properties of the
The advantage to an Interface is that it provides a common specification for all classes that use
it, while allowing each class the flexibility of implementing the details of the common specification
in its own way, as well as the flexibility of adding other functionality to the base specification.
The classes that implement the Interface must implement all members of the Interface: In fact,
the VB Compiler will enforce this requirement, giving you error messages if you forget to implement
all the members of an Interface in an object class that uses the Interface.
Continuing with the example of Vehicles, imagine an Interface class called IVehicle. (The I at
the beginning of the class name is a standard naming convention for Interfaces.) IVehicle contains
properties such as Speed and MaxSpeed and methods such as Travel. You could create other classes
such as Automobile and Airplane that implement IVehicle's members, each in its own way.
The Automobile and Airplane classes might also implement methods and properties of their own
apart from the Interface (such as OpenTrunk or LowerLandingGear).
NOTE - Interface Classes as Abstract Classes: A
lot of documentation refers to a VB Interface class as an "abstract class." Conceptually,
this is true, because you are using an Interface as a model for other classes
without specifying implementation details. Strictly speaking, however, it should
be impossible for an abstract class to be instantiated or hold any code. Because
it is possible to write code in a VB Interface class (although this isn't often
done), and because it is possible to instantiate an object from an Interface class
in your code, a VB Interface class is not technically a true abstract class