Interface confusion...

[JaseUK]

Dear all,

I am writing an ActiveX DLL that conatins objects for accessing a database. The hope is that it will ultimately provide a set of objects for developers to use when writing applications that integrate with our system.

So far I have organised it thus: Each object contains properties and methods for accessing and manipulating database tables (EG: high level commands such as SaveChanges, AddNew, Delete). The objects are organised into collections so that navigation is much like a tree structure. EG: Company(1).Addresses(x).Town etc etc etc.

I have this structure working but have noticed that each table and collection object contains much the same code that I would potentially implement time and time again. My question: Can I / how would I use interfaces to make my job simpler?

The typical structure of each TABLE object is this:
- List of properties (fields)
- Parent object reference
- Collections of sub-objects
- Initialisation & Termination
- Delete, Add, Save public methods
- Associate, Populate, Disassociate, Build friend methods

The code is fairly similar in each object but obviously the properties change. Please help: Is there any advantage to using interfaces!!??

Jason.

 

[WilMead]

I'll start by saying I cannot answer your question about using "interfaces."

On a design level one would have to say that your object model lacks definition. You have some base classes yet to be defined. These classes encapsulate commonalities found in your other objects resulting in more classes but less redundant code.

What you defined above should be your only BaseTable object, all tables are the same, just as you defined them. Using that object create specialized table objects leaving all that common code in one place. Most OOL Allow drivation and make inheritance transparent. VB, on the other hand, does not make it easy. VB provides the Inherits statement but I'm not versed in it and cannot speak well for it. I can say that it does teach you what goes on in inheritance. Basically you embed the base classes object and wrap its members so they look like that are part of the derriving class.

Your generic table trivializes the field names, leaving them to the Fields object. It includes the other member properties and methods you mentioned above, but only on a generic level, the level that remains unwavering in your current implementation. The derriving classes embed this object as a private member and provide members with the same interface as the embedded base class object. The difference here is that the derived class relays parametric information to and from the embedded object. Of course, you can add any special processing before and after using the base class member, you can even omit the base class member thus completly specializing it in your derrived class.

Example Class1 to derive from a base class:
[tt]
Private oBaseClass1 as cMyBaseClase
Private Sub Class_Initialize()
set oBaseClass1 = new cMyBaseClase
oBaseClass1.Init "My Specialization data"
' My initialization specialization
End Sub

Private Sub Class_Terminate()
' My termnination specialization
oBaseClass1.Term
set oBaseClass1 = Nothing
End Sub

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

 

[meadandale]

I wasn't aware that VB supported interfaces...

In any event, in programming parlay, an interface creates a 'type'. Any object that implements that interface is guaranteed to expose the operations of 'type' and have them work in a consistent manner.

In general, interfaces define no code, only behavior (i.e. functions or methods).

E.g.

public interface Runner
{
public void run();
}

public class Animal implements Runner
{
public void run()
{
// do the running
}
...
}

In this case, an animal 'is-a' Runner. I can convert an animal to a Runner object via a cast and use it as I can ANY Runner. The interface is the same.

Interfaces, as such, allow multiple inheritance of behavior in all languages (I dont' consider VB a programming language, it is more of MS scripting) including Java, which doesn't support the C++ idea of multiple inheritance.

Hope you aren't confused. I'd suggest that if you want to do OO programming that you use an OO language, not VB 8^)

 

[WilMead]

I suggest that if you really want to understand Object Oriented Programming you try a language not designed for it and make OO happen.

The choice of forums for the original discussion leaves a little to be desired here. The question is actually better in the VB classes and Modules forum. The concept was never in question, the discussion was more about how to make it work for you in VB. Or for that matter make it work at all. Actually, the question was, should one be concerned about making it work? I guess, to you, the point is moot.

The Implements statement forces one to follow class based OOD rules. It does this at compile time by assuring that all public members of the base class or interface are accounted for, throwing an error otherwise.

As I stated, the Implements statement allows you to better see how an object goes about polymorphing. The "embed and wrap" methodology I indicate gives you choice over what gets implemented or re-exposed from the base class. Since the process uses another object, not the description of that object, as a template one might say that the model is prototype based instead of class based. Don't be fooled, you still need to know the description... or do you? ;-)


Sunil asked the question about prototype based Objects in thread678-189635.



Wil Mead
wmead@optonline.net