>As I've studied OOP a little more recently, I hear of this matter of depency injection. Can someone help explain this to me, from a VFP perspective.
>
>I think my question here may be associated to it... On my form class, I have a method that will calculate the total amount of the invoice, by summing the line item costs based on the parent key.
>
>So, I have a method on the form called CalculateLineItemCost().
>
>Now, I could architect this thing where the method assumes the current parent key from a form property which is (kept updated by the navigation of the form), or I could architect it to where the parent key value has to be passed into the method by the calling method.

I think neither is related to dependency insertion as described there. By there definition, dependency insertion would mean that your object doesn't even calculate the cost itself, it calls this.oSomeServiceObject.CalculateLineItemCost(params), without giving a damn to check whether it has one or not - it's the responsibility of its container object to provide one, i.e. to set this.oMember.oSomeServiceObject=oRefToTheActualServiceObject, which needs to exist already or be created on the spot. So your object only needs to call the service, but doesn't need to have the code to instantiate it or find it or even check for it, that's the responsibility of the .parent, which then needs to have all that code only once. The code I'm talking about is three lines in VFP... OK, four:

procedure oSomeServiceObject_access
if type("this.oSomeServiceObject.name")#"C"
   this.oSomeServiceObject=createobject("SomeServiceObjectClass")
endif
return oSomeServiceObject

This is, roughly, 145. time I wrote these four lines ;).

So... your bizobject, which should do these calculations for you, can be implemented as a concern of the objects which call its code, or of their form. Your call.