[At some point, business objects need to have a reference to a common app object, so that settings can be changed in one place (at run time).]

Not to start a controversy, but I think that this statement is totally incorrect. I know that there are many frameworks and developers that take this approach, but it does not create properly encapsulated objects. Why would you need an application object, which presumably maintains state,manages session information for the user, and exposes methods related to the context of the session, just to create a business object which shouldn't really care or know about these things.

Take it to the next level - what about creating a COM object that is a business object. Say, from ASP or even a VB app. What would be the purpose of the application object in this scenario? Creating a dependency on the application object effectively rules out the use of the business object outside the context of an application that implements the developer's application object. This is not proper encapsulation.

That being said, it is a good idea to be able to store configuration information at the application level and pass that information to business objects when there is a session to be managed and the app is stateful in nature.

Personally, I borrowed some concepts from Java to implement my approach to this problem. Java has constructors, which allow for objects to have different behaviors on creation depending on the parameters sent to them. It is possible to duplicate this functionality in VFP by checking for the number and types of parameters. Although in my case I took this stuff out of the Init and put it in a SetObject method because of some of the issues with Init and COM. So my approach was as follows:

First, I created a Metaobject. A Metaobject is an indepedent object that stores collections of Parameter objects. Parameter objects can also be created independently. For argument's sake, let's just deal with one for BizObjects, and call it BizObjParameter.

A MetaObject can be pointed at a path, which contains files that can be used to populate the MetaObject's collections. It can also be set programatically.

The BizObject can then take the following:

A BizObjParameter [oBizObject.setobject(oBizObjParameter)]
The name of the object and a MetaObject
[oBizObject.setobject("MyBizObject",oMetaObject)]
The name of the object and a path
[oBizObject.setobject("MyBizObject","C:\MYPATH")]

This allows you to:

Create a BizObjParameter object, set configuration information directly, and send it to the BizObj.

Have an existing MetaObject (say, one contained by the application), and pass the name of the the business object you want and the MetaObject to the BizObject for configuration.

Pass the name of the object and a path to the location where configuration information exists. In this case, the BizObject will create it's own MetaObject to get it's information about how to configure itself and manage it's own environment.

This way,

oBizObject=CREATEOBJECT("MyBizDLL.MyBizObject")
oBizObject.setobject("MyBizObject","C:\MYPATH")

works too. The business object is independent. But because of the common transport mechanism for configuration information, the only "extra" work for the business object is to figure out from the parameters passed how to get the configuration information it needs.

I know that this is a long post and I started out a bit strongly. I hope nobody will take offense to my tone here - no offense intended...

Hope that this helps instead of just confusing things for you further...

>>>>>Dear All!
>>>>>
>>>>>I am on rewrite my semi-OO application to meet the closest criteria of OOP.
>>>>>
>>>>>My first big problem I faced, how to give the info to my BusinessObjects about envirometal data (e.g.: path of database files, ... etc.)
>>>>>
>>>>>I identified two main algorythm:
>>>>>passing the an object parameter to init method
>>>>>creating the enviroment object internally
>>>>>
>>>>>Which one fits best into the world of OOP?
>>>>
>>>>Business objects in most frameworks either search for these properties in an application object, or in the parent form, which probably got them originally from an application object. Only if the object is not contained and the application object cannot be found, it should take on a set of defaults, or instanciate an application object that knows how to establish defaults.
>>>
>>>Dear Erik!
>>>
>>>My app used the first way you mentioned. My objects used the properties of main application object. I thought it is not compatible with Encapsulation because an object is depending on an other object. (Business objects are depending on application object.) I had only one public variable (goApp) and all object used it. I am afraid to use referencing the app object via object property because of possible refrence dagling. (i.e. pass a refrence for the App object and save it into a property variable in a Business object). So I thought to create an enviroment object internally or pass it as parameter and save its properties into object properties of Business object.
>>>
>>>BB
>>
>>At some point, business objects need to have a reference to a common app object, so that settings can be changed in one place (at run time).
>>
>>As far as dangling object references, just kill the object reference in the BizObj's Destroy event with THIS.oAPP = .NULL.. Doing this at the class level should take care of the problem for good.
>>
>>The way that you Decouple the business objects from the app object is have them know how to live without it. This might mean resorting to default settings in the class definition, pulling default settings from the registry or from a system settings table, or preferably create the app object (as a public object, so all business objects don't have to do the same thing) if it does not exist, and let the app object figure out where to get default settings from.
>
>Dear Erik!
>
>I wrote some generic procedure that use the goApp variable (and so, assume that it exists).I thought it is a mistake. So, then it is not, or is it? If it isnot, what is the Encapsulation at all?
>
>BB