Vb Classic Has No Inheritance

See InheritanceInVbClassic

Often used as a proof of the lack of object-oriented-ness (whatever that means) of VbClassic, and therefore it's unusability as a language for real programmers. The argument is total rubbish of course.

- VB6 supports InterfaceInheritance but not ImplementationInheritance // Not true. See below.

- VB.Net (VisualBasicDotNet) supports InterfaceInheritance and ImplementationInheritance

Since most OO texts never draw a distinction between ImplementationInheritance and InterfaceInheritance, we'll just have to keep guessing whether VB6 is OO or not...

In VB5 and VB6, Classes can have several interfaces. If a class implements an interface, it just has an interface more. It is not possible to create a new interface which inherits from another one. It is not possible to create subtypes. Objects can have several types, but there is no hierarchical relation between these types. (Except very few special cases, like: instances of any user-defined form (not UserForm??) are also of type Form.) If you want to use an instance of a class which implements several interfaces, you have to decide which of these interfaces you want to use. VB does not create a new interface which combines the features of the different implemented interfaces.

On interface inheritance/extension: You can declare that "every class that implements IX must also implement IY," and thus achieve a similar effect to IX 'inheriting from' IY. In practice, interface inheritance has proven to be a bad thing in COM, and Microsoft discourages its use: IMoniker inherits from IPersistStream, which "seemed like a good idea at the time". But now we have IMoniker implementations that don't implement any IPersistStream methods (returning E_NOTIMPL for all of them). This is bad style; it violates the interface contract. But because interface inheritance was used, this can't be fixed. -- JeffGrigg

Of course, one might argue that the underlying problem here is with the design of COM...

Or not. COM got it right with interface inheritance which influenced the design of Java as well as others...

VbClassic has had polymorphism via InterfaceInheritance since VB3. And that's the important part.

VB before VB7 does not support ImplementationInheritance (see above). The keyword "implements" works since VB5. VB does support polymorphism via late binding since VB4 and via variants since VB1.

ImplementationInheritance can be a real convenience, especially when you wish to conditionally override functionality, as is common in frameworks. But one can be quite successful even without some of modern life's conveniences.

Undoubtedly it can be useful, but it can also lead to the FragileBaseClassProblem, especially at a component level.

Overriding functionality is often best done via an interface rather than a base class. ImplementationInheritance often introduces a fuzzy contract between base class and deriving class. This can be hard to test; interactions between base and derived can be complex and hard to understand; and it can result in a very hard to change base class.

I am not sure what you mean by fuzzy contract; the base class has a contract to support all methods that are accessible from the derived class. This applies to variables too, though I have come round to the thinking that variables should be accessible only via accessor methods, even to derived classes. The question ShouldMemberVariablesBeAccessibleToDerivedClasses is debatable.

I agree I was being unclear. What I meant is that it may be clear when first written, but can easily become fuzzy over time, i.e. nobody knows what it does or it becomes very complex.

Many Java programmers would do well to remember this contract, and use private or final where they are not certain that future implementations will stick to it.

CategoryVbClassic