I do have one central application object and I am very happy I did it this way.

The advantage is, that the logic of creating the different objects can be centralized in this object. If you have to exchange one object with another one later down the road, you can adjust the code in your central application object, and that is the most sensible place to do that. You can implement factory methods that have a more extensive logic involved in creating those objects.

Also think about lazy instantiation: you can create ACCESS methods that will create certain objects on demand, so you don't have to load all objects at starting the application.

Another good example is changing a single object into a collection: In my old code I had one ActiveDatabase object. Later it turned out I needed a collection, so I removed the object reference and instead created an ACCESS property that would return the currently selected database as ActiveDatabase. I could refactor that code in the application class, without changing any of the other calling classes.

>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