Does Visual Basic support multiple inheritance? That is one child
class inheriting from more than one parent class.
JD
-
Does Visual Basic support multiple inheritance? That is one child
class inheriting from more than one parent class.
JD
-
Re: Multiple Inheritance?
Joe Delphi wrote:[color=blue]
> Does Visual Basic support multiple inheritance? That is one child
> class inheriting from more than one parent class.
>
>
> JD
>
>[/color]
Visual basic (up to vb6) only supports interface inheritance. You can,
however, implement more than one interface. In theory, you can inherit
any interface you like (at least, that's what the documentation says).
In practice, there are some VERY restrictive rules that spoil everything:
- underscores are not allowed in an interface procedure name. This means
that all useful standard interfaces (like RecordSet, Collection, etc.)
can NOT be implemented, as they all have a (hidden) member with an
underscore in its name.
- all procedures of an interface have to be PUBLIC. For some obscure
reason, VB won't allow you to use FRIEND members in an interface.
Best regards
-
Re: Multiple Inheritance?
"Joe Delphi" <delphi561@nosp am.earthlink.ne t> wrote in message news:<Bv3Bc.750 2$w07.6044@news read2.news.pas. earthlink.net>. ..[color=blue]
> Does Visual Basic support multiple inheritance? That is one child
> class inheriting from more than one parent class.[/color]
VB doesn't support inheritance at all. You can implement multiple
interfaces and use delegation to simulate inheritance but that's as
close as you get.
Comment
-
Re: Multiple Inheritance?
"Dikkie Dik" <Abuse@SpamBust ers.com> wrote in message
news:40d5929b$0 $921$5f6aeac3@c ust-dds.news.scarle t.nl...[color=blue]
> Joe Delphi wrote:[color=green]
> > Does Visual Basic support multiple inheritance? That is one[/color][/color]
child[color=blue][color=green]
> > class inheriting from more than one parent class.
> >
> >[/color]
> Visual basic (up to vb6) only supports interface inheritance. You can,
> however, implement more than one interface. In theory, you can inherit
> any interface you like (at least, that's what the documentation says).
> In practice, there are some VERY restrictive rules that spoil[/color]
everything:[color=blue]
>
> - underscores are not allowed in an interface procedure name. This[/color]
means[color=blue]
> that all useful standard interfaces (like RecordSet, Collection, etc.)
> can NOT be implemented, as they all have a (hidden) member with an
> underscore in its name.
> - all procedures of an interface have to be PUBLIC. For some obscure
> reason, VB won't allow you to use FRIEND members in an interface.
>[/color]
Just wanted to add a different view of interface implementation. I have
found it to be very useful and powerful for elaborate application
development, and use it all the time.
The intent of interface implementation is not to allow implementing just
any class, such as the RecordSet or Collection classes mentioned, but
rather to allow implementing any interface which is meant to be
implemented.
The usual approach for an application that needs its own RecordSet or
Collection implementations is to create your own classes and interfaces,
and write all your code to use these. Then you can embed recordset or
collection objects within the implementations if needed.
Here is the beginning of one class I have in a large application:
'CPipe
Implements IListItem
Implements IDBItem
Implements IWizard
Implements ILayoutData
Implements ILayItem
Implements IDataLayDgm
Implements IDataMark
Which means this class can be:
Added to a custom collection class.
Saved and restored from a file.
Edited using a Wizard form.
Displayed in a grid or printed on a report.
Placed in a pipe line design.
Drawn on a plan and profile CAD drawing.
Drawn on a shop production CAD drawing.
Most of the code for this class is in the interface implementations .
Other classes also implement some or all of these interfaces. The main
processing code is written around the interfaces, not the instance
classes, so they can process a mixture of actual objects - polymorphism,
in other words.
When several classes need to implement the same interface using the same
code, I create a base object, and embed one in each class. For instance,
CPipe, CElbow, and CReducer all use a CDataMarkBase object to implement
portions of the IDataMark interface. This is the VB way to simulate
inheritance.
In my opinion, it works out quite well, and can produce powerful, well
structured, and extensible applications.
One future extension may be the addition of a pipe with a split end or
"Y" shape at one end. I will create the CWye class, and add an option to
put one in a layout. Once CWye implements the above interfaces, all of
the processing operations of the program will work just as well with the
new class as they now do with the existing classes.
Apologies for turning this into an essay - its just too hot to go
outside. :)
Comment
Comment