>>>Hi Experts,
>>>
>>>I have a question re best practices on creating an Application Object.
>>>
>>>Should objects coming from say a Connections Manager or Forms Manager be a member object of - already instantiated - by the Application Object like so:
>>>
>>>
>>>oApp = CREATEOBJECT ("myApplicationClass") --> also instantiates oFormsMgr, oConnMgr
>>>oApp.oFormsMgr.MyMethod()
>>>oApp.oConnMgr.SomeOtherMethod()
>>>
>>>
>>>or can exists 'stand-alone', like so:
>>>
>>>oApp = CREATEOBJECT ("myApplicationClass")
>>>
>>>IF NOT oApp.Connect()
>>> MESSAGEBOX( 'Unable to connect' )
>>> ** do whatever else
>>>ENDIF
>>>
>>>PROCEDURE Connect
>>> LOCAL llResult
>>> oConnMgr = CREATEOBJECT( 'myConnectionMgr' )
>>> llResult = oConnMgr.Connect()
>>> RETURN lnResult
>>>
>>>
>>>Thanks in Advance
>>>Dennis
>>
>>I guess it depends but your second option doesn't look good if you need 'myConnectionMgr' to stick around. Why not make oConnMgr a property of the app but use an access method that will create it if required. Something like:
IF This.oConnMgr = .F.
>> THIS.oConnMgr = CREATEOBJECT("ConnMgr")
>>ENDIF
>>RETURN THIS.oConnMgr
>>That way you can still use code like 'x = app.oConnMgr.Connect()' but without incurring the overhead of creating an instance of ConnMgr unless it is required.
>
>
>Don't want to nit-pick, but it may be better to create the object directly in the init, ie not use an access method
>
>Access methods - in vfp - are slow and multiply the time to access the object by a factor of 5
Are they really that slow - I wonder why?
I guess these decisions always imply a trade-off.
If the ConnMgr may not be needed then creating it in the Init() is a waste of time.
OTOH, if access methods are as slow as you imply and the object is referenced a lot (which, I admit, sounds more likely) then creating it at startup will be better.