>I've been considering an aspect of an object oriented framework I created a while back. This framework was based on business objects, much like codebook. A business object is basically a container for a particular part of your buisness.
>
>For example, a rolodex business object would contain all the code to deal with adding / deleting /updating rolodex "members" ("data" in non-OO terms). So, once you have your rolodex object you can drop it on a any form and you would have the functionality you needed. I like the idea that the business object is self-contained--as a good object should be. However, I am undecided on just how far I should take the object oriented model.
>
>One concern is the dataenvironment. The business object is not actually self-contained unless it has it's own dataenvironment. As we all know, the VFP dataenvironement class can not be visually subclassed, only programatically. In programatically subclassing the dataenvironment we are left with a non-visual dataenvironment. I can't decide if staying with the object oriented model is worth the added headache of giving up the nice visual VFP dataenvironement.
>
>Another concern is data manipulation. In a perfect OO world, only the corresponding business objects can deal with any aspect of its members. This means that, in the case of the above rolodex example, only the rolodex business object could modify rows in the rolodex table. However, there are some cases when other business objects need to update that particular table. Does this mean that I now have to instanciate the rolodex business object and submit the proposed changes through it or should the business object be able to manipulate the table directly?
>
>To reiterate briefly: 1. Do you feel that subclassing the vfp dataenvironment is more headache than it is worth? 2. Is the self-contained business object a good thing or should you be able to manipulate data directly?
>
>
>Any comments are appreciated.

Michael,

Your question about the .DataEnvironment, and OOP in general, raises several other issues. Before dealing with those, however, let me address subclassing the DE.

While it's true you cannot subclass the DE, there's nothing to prevent you from writing your own custom class that contain the same elements. However, the question in both cases is would it be worth it? In my view, the answer is no. The reasons for this answer may provide you with some additional insight into how to approach development.

One principal in the OOP methodology is reusability. A key here is simplicity. As an object's complexity grows, it reusability diminishes proportionately. If you could subclass the DE, or wrote a custom class, how often would it be reused? In my work, the answer is little if at all.

The subject of encapsulation is a matter of definition of the object's purpose. Looking at the Tasmanian Traders sample application, I can easily see an area where I would disagree with how the purpose of a data input form was defined. In the sample, each data input form contains methods to move the record pointer. Now it can be argued that this is necessary to achieve encapsulation. However, if the defined purpose of the form is to simply recieve input and display record contents, then it could also be argued that placing such methods in form object are both unnecessary and overly complex. Additionally, it takes longer to load and display the form, redundant code can be placed into memory, reducing both what's available and performance. Further, if some code in one of these methods is modified, compile time will be increased. It should be remembered that another goal of OOP is to ease maintenance. To me, it makes far more sense to place such methods in their own non-visual class.

To sum this thing up, the most important element in development isn't necessarily how closely we adhere to our preceived notions of following the OOP methodology. Rather, it's how we define the purpose of the objects. If you can define the object (what it does) in a simple sentence, then you've probably made the object as reusable as possible and are still adhering to the methodology.

HTH,

George