>Sorry, but no way... that's too broad of an application of this principal.
>
>You can't tell me that goApp.oCurrentUser is not a reasonable thing to have in an app while still maintaining good code structure and design principals.
>
>And so forth...
>
>As a minimum the various features, properties, and general functionality that I was seeking suggestions about could live in separate objects as appropriate and then references to the individual objects could be hosted on goApp.
>
>For instance, goApp,oConfig

Single responsibility of housekeeping?

I put in oApp all the things I need globally and which don't need to run in the current datasession (or I have to pass the set("datasession") as a parameter). So yes, oApp.oConfig, .oCurrentUser, .oMainToolbar, .oLogger, .oTranslator and that's about it. In earlier lives of it, it used to also host things like .oZipper, .oMainMenu, .oSecurity, .oDbConnection, but as these aren't necessarily parts of every app where this class is used, they became optional.

Now that the machines are fast enough, all the considerations about the instantiation times are kind of obsolete. It's more about developer's time and ease of maintenance, so most of these optional components are created in their *_access methods, i.e. on demand. So I know that these will be there if I need them (i.e. code won't break because the object isn't there) and yet they won't delay the launch by building dozens of them every time. Now this may sound contradictory, I just said instantiation times are now negligible - however, some may involve pulling a lot of data from the server, which may not be a good idea if the user launched the app just to look at something unrelated. So, instantiate on demand.

The tricky part is the order of instantiation. Quite often, an object which I need to add to oApp needs the services of another one, and sometimes I did get into "A needs B and B needs A and I can't instantiate one of them without the other" vicious circle which couldn't be solved without some refactoring, i.e. moving those dependencies into some C that would be instantiated before both A and B. Ditto for destroy - for instance, the logger dies last, because if it's destruction after a serious error, I need some trace of the event, so other objects may need to log their .destroy().