Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Another Speed Thingy
Message
From
01/11/2003 06:43:03
 
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00843972
Message ID:
00845332
Views:
19
Hi Nigel,

>The players...
>
>oParent = Application Object.
>oChild = Instantiation (on oParent) of VFP DLL to do calculations.
>oForm = A Form (managed by oParent).
>Procedure = A Procedure.
>Controls on oForm need to call methods in oChild. There will be quite a few calls on each form.
>A) oForm.Control calls Procedure which in turn calls oParent.oChild.Method
>B) oForm.Control calls oParent.Method which in turn calls oParent.oChild.Method
>I cannot call oParent.oChild.Method directly as I need to ensure that oChild exists and don't want to repeat the checks everywhere.
>
As usual, it probably depends...

First: if the calls to oChild are in the range of millions, I'ld instantiate it as another global/private object and not as a property in goApp. That way you need one redirection less.

If it can be assumed that most of your installations need the real calculations, I'ld ALWAYS install ***A*** oChild, but that oChild only has the interface and returns the things your Proc does if the oChild isn't needed for calculation. This way you just have one call to the factory-type pattern at goApp's start and don't have to always go via Procedure to check for the objects instance.

If most installs don't have oChild, I guess Procedure is the way to go.
There you can check for the [g]oChild and call your calc method[s].
If there are only a few methods on oChild, I'ld skip the object and implement them in a procedure libray, or if they call many functions of this object / proc library ***during*** one calc-call I'ld consider moving the calculation into a .fll.

Crossing COM-Boundries takes much more time than calling a method on a normal object. If the number of calls to this object are high enough to warrant moving oChild from goApp to a global var, I'ld think about a factory pattern to instiate not from a COM-Dll but from a "normal" vcx or prg/app.

But to be honest: if your calc-object is called more than a few hundred times, I'ld be suspicious of the design. If it is called more then 10000 times, the effects *might* be measurable, but I'ld be ***very*** suspicious of the design <g>.

my 0.02 EUR

thomas
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform