Inheritance in VB

[JaseUK]

Dear all,

As far as I can see the implements statement in VB allows you to specify a prototype/interface for a class and nothing more unless you deal with the call in the class that inherits the code and then call the code in the inherited class.

What I need to do is this: I want to be able to create a class called Table with methods such as "Add", "Delete", "Update" etc. I then want to be able to build objects such as "Addresses" that "fill-in" the blank details in the middle of the Add, Update and Delete methods with the correct fields and SQL. Should I just pass by value into a generic "table class" or use the interface/inheritance provided in VB6 and write the methods out in each specific class.

The only real benefit I can see with the VB6 inherits statement is that you can use polymorphism accross classes so that users of the objects or object friends understand the way in which they interface/interact with the object being provided without needing to understand the specific type or "table" that it is dealing with. This means that at design time I can manipulate the objects with their methods as they all conform to a "template"/interface, where as I would not be able to if I used the type "Object" that can accept any Object types.

Basically: How do I achieve what I am trying to achieve!!?? Very muddled.

Many TIA,
Jason.

 

[WilMead]

This is not much different than your other thread. It sounds like your methods seem to have a lot of deviation from a common code base, the other question was leaning to common code.

For what you want, don't use the implements statement. Just put your specialized code in each special table class. In your basic table class, collect all the code that never changes, or at least changes only in one or two of the special classes.

Use the embed and wrap style to make the common code look like it's in each of the special classes, tuning it as needed. The nice thing about the VB inheritance model's lack of definition is the total control you get over it.


One last note, the object or variant types may not display the helpers at design time, but that does not mean that they aren't there. I think you already know this though.


Wil Mead
wmead@optonline.net

 

[JaseUK]

Wil,

Thanks for the info - sorry for creating another thread - they are pretty much identical. Could you just clear up for me what you mean by the "embed and wrap style" and how I go about programming it.

TIA,
Jason.

 

[WilMead]

By embedding I mean to include a data member of your parent class. This gives you the base object to work with. In order to make the "inheritance" work you need to provide the relay mechinism or wrapper. Using the same name as the base class's member makes it transparent to the derrived class's consumer. The example thread678-195102 shows this.
[tt]
Private oBaseClass1 as cMyBaseClase ' Embed base class
[/tt]
The Parent Property wraps the base classes Parent Property making it look like it's just another property in the derrived class. In this case, the parent object gets passed back and forth. (Please excuse poor choice of property name!)
[tt]
Public Property Get Parent()
Set Parent = oBaseClass1.Parent
end property

Public Property Set Parent(oNewVal)
Set oBaseClass1.Parent = oNewVal
end property
[/tt]


Wil Mead
wmead@optonline.net