>Are you ready to start a VB training ?

Training VFP Developers on how beneficial VB could be? That could be the toughest job on the planet... Any ideas???

>I understand the instance of the second class creates the instance of the first automaticly ?
>

So we agree that an issue does not really exist here.....

>My application has a public interface . So I know how OO is implemented in COM . But I understand this thread more as a VFP/VB OO comparaison .
>
>I understand the power of a implementation inheritance (Like C++ and Java )
>but can you explain me the power of a multiple interface.

If you understand COM, then you understand that multiple interface support is how polymorphism is supported in COM.

Consider this example: you have a generic interface for a complex calculation class. In your app, there are many different ways to actually carry out the calculation. Nonetheless, you have published a contract that all variations must subscribe. Ergo, you have published a standard interface. In this example, we have one method: RunCalculation. Here is the prototype:


Public Function RunCalculation(x As Integer, y As Integer) As Integer

End Function


At this point, we not only have an abstract method, no implementation exists. The name of this class is BaseCalculationClass. Now, lets say you have two ways to run the calculation. You can either multiply or divide the passes parameters. The first one we will tackle is the class that will multiply the numbers. The first step we need for this class is to implement the interface of our BaseCalculationClass Class:


Implements BaseCalculationClass


Now, we can attach the actual implementation code:


Private Function BaseCalculationClass_RunCalculation(x As Integer, y As Integer) As Integer
BaseCalculationClass_RunCalculation = x * y
End Function


Now, our second class has two interfaces, its own, which has no members, and the interface of the BaseCalculationClass Class.

Now, lets create another class that alters the calculaton by dividing the numbers instead:


Implements BaseCalculationClass

Private Function BaseCalculationClass_RunCalculation(x As Integer, y As Integer) As Integer
BaseCalculationClass_RunCalculation = x / y
End Function



Now, lets put the stuff to work.

First, lets get instances of our calculation classes:


Dim oDivide As New DivideCalculation
Dim oMultiply As New MultiplyCalculation
Dim ocalc As BaseCalculationClass
Set ocalc = oDivide
Print ocalc.RunCalculation(100, 10) ' prints 10
Set ocalc = oMultiply
Print ocalc.RunCalculation(100, 10) ' prints 1000


Lets go through the possible solutions:

1. You could create a case statement that accounts for different operators and acts accordingly. To a point, this works. But, as time goes on, as functionality needs to increase, this solution does not scales. Rather, a big monolithic code block begins to evolve.

2. You could use inheritance. Well, in reality, inheritance really fouls things up here. Lets review for a moment what our goal is. Our goal is to get polymorphic behavior for our interface. In this case, the only thing I concerned with inheriting is the interface, not the behavior. With VFP, I am forced to use inheritance as my way of achieving polymorphism. Now, I have to create a base class, and then I have to create two subclasses. So now I have this:


Parent
DivideSubclass
MultiplySubclass


And for what reason? It's not to reuse code. It's for implementing an interface. In reality, inheritance is a lousy way to reuse code. Code reuse is achieved though good class design, and the implementation of those classes. The biggest use of inheritance is in the UI. That is where I save the most work through inheritance. As for business rules and logic, the importance of inheritance is next to squat. In reality, your need is to implement interfaces.

If you think you save a lot of work in VFP, I would have to disagree. Here is the VFP code that does the same thing we did in VB above:


oDivide = Createobject("DivideCalculation")
oMultiply = Createobject("MultiplyCalculation")
ocalc = oDivide
?ocalc.RunCalculation(100, 10) && prints 10
ocalc = oMultiply
?ocalc.RunCalculation(100, 10) && prints 1000


What did inheritance buy us here? Other than implementing an interface, nothing. You still need to write you implementation code in each of the subclasses. There is no savings in work whatsoever. In fact, there really isn't subclassing at all, since we are not inheriting anything anyway. So, why deal with inheritance in the first place. It just complicates things. In VFP, to achieve polymorphism, we are forced to do so. In reality, it's all about implementing interfaces.

Now lets say you have a need to implement common pre-processing and common post processing for the calculation. It sounds like a ripe opportunity to take advantage of inheritance...right? I would tend to agree.

The common perception in the VFP world is that the folks in VB have to copy and paste the code. Fact is, many folks do that. Fact is, many VFP developers are guilty of the same crime!!<bg>. In VFP, to accomplish this task is a snap because we have inheritance, right? Think again. You can't simply put the calls up in the base class. Rather, you will need to make the pre and post processing calls in your implementation code. Here is what it looks like in VB:


Implements BaseCalculationClass
Dim oBaseCalc As New BaseCalculationClass

Private Sub BaseCalculationClass_postprocessing()

End Sub

Private Sub BaseCalculationClass_preprocessing()

End Sub

Private Function BaseCalculationClass_RunCalculation(x As Integer, y As Integer) As Integer
oBaseCalc.preprocessing
BaseCalculationClass_RunCalculation = x / y
oBaseCalc.postprocessing
End Function


Here is the BaseCalculationClass Defintion:


Public Function RunCalculation(x As Integer, y As Integer) As Integer
End Function
Public Sub preprocessing()
MsgBox "pre processing"
End Sub
Public Sub postprocessing()
MsgBox "post processing"
End Sub


Here is the VFP code:


Define Class DivideCalculation As BaseCalculationClass
Function RunCalculation(x , y )
This.Preprocessing
Runcalculation = x/y
This.PostProcessing
Return Runcalculation
End Function
EndDefine

Define Class MultiplyCalculation As BaseCalculationClass
Function RunCalculation(x , y )
This.Preprocessing
Runcalculation = x*y
This.PostProcessing
Return Runcalculation
End Function
EndDefine

Define Class BaseCalculationClass As Custom
Function RunCalculation(x , y )
End Function

Procedure Preprocessing()
Messagebox("Pre Processing")
EndProc

Procedure Postprocessing()
Messagebox("Post Processing")
EndProc
EndDefine


Where is the work savings inheritance is supposed to provide. In this case, we need to set inheritance aside. In fact, we are working around it. Once again, the only thing we are doing is implementing an interface. And, even that is somewhat semantical since there is no strong typing in VFP. At least in VB, it is enforced. If you partially implement an interface, you will get compile errors in VB.

Now, is this the correct approach in ALL situations. Of course not. What is important to note is that in the bigger world of COM, this is how it's done. It is neither good nor bad. It is a what is. Whether how things work in VFP is compatible or not compatible, that is of no matter. It is what is. And, it would behoove folks in the VFP community to understand how the other side of the fence operates.