Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Encapsulation and enviroment
Message
From
27/06/1999 13:50:07
 
 
To
27/06/1999 13:42:04
General information
Forum:
Visual FoxPro
Category:
Object Oriented Programming
Miscellaneous
Thread ID:
00234491
Message ID:
00234525
Views:
24
>>>>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
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform