>>>>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
>
>I did not know that. Thanks.
As I told to Denis - there is no reason not to use them - time may not be significant
It's just a bit different than in .NET - here we like the 'overhead' of creating an object - since it's usually faster - unless creating it would take significant time and the odds of using the object are close to zero. In short - it depends
Gregory