>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.

I am by no means any sort of OO expert, but I think one piece of insight can be given from any observer...
OO is not a scripture passed down from the heavens. It is not a law or a rule that from hereafter developers must adhere to. It is a methodology designed to make design and implentation easier. If a certain OO principle dictates that a routine/ module/ class be designed in a way that is difficult or cumbersome to do with a given design tool, what is the point? If in the long run you feel that subclassing the DE will save time and effort then that is the most logical choice. If however you find yourself writing code that makes your life more difficult, you should stand back and take a good look at why you are doing it. Don't go out of your way for compliance with a concept that doesn't do any good. (I am not saying that subclassing a DE is not a good idea, only that it should not be done simply for the sake of a philosophy.
I think the same approach should be taken with the business object. The reason for business object is to ensure consistent interfaces with data, and that the same rules are applied no matter what form is updating the data. If the secondary forms are dealing with parts of the record that the business object was specifically designed to govern, then yes, you should instantiate it. If another form is simply toggling a boolean field or changing a date or something, ask yourself if the business object really has a place in that form.
OO is beautiful and almost necessary for good design, but its principles are guidelines and suggestions, not steadfast laws. The bottom line is still ease of implementation, data integrity and performance, and those should not take a back seat to anybody... not even OO principles.