Hi Alex,
The delineation between objects is somewhat of a personal preference. Most of the exaamples I have seen have objects that are based on more concrete things as opposed to abstract.

For example, a lot of developers make reference to an oUser object. This object would have properties and methods associated with a system user. It may have properties for the user ID, their password, etc. oApp (properties and methods needed thoughout the application), oSecurity (PEMS used to determine user access to various things), oReport (create and run reports) and oforms (form manager) are other examples.

I would suggest against creating something like oCalc because it sounds as though you would many types of calculations housed in this one object. In my mind, objects are homogeneous. Everything about them revolves around a common theme. Methods exist within objects that perform many calculations that are unique to that object. For example, accrued vacation would be calcualted in the User or Employee objects. If you had special algorithm needed in several places throoughout your code, then creating an oCalc object that accepted parameters and performed the calculation would be a great way to go.

As Alex suggested, I also recommend a framework. Not necessarily to use with your project but to use as a learning tool. Some of the best developers in VFP have spent a lot of time and effort into creating these commercial frameworks and you could probably learn alot from any number of them.

Good luck!

>Hi,
>
>I have a large app that I am moving to VFP. I have been doing things in a very non OOP way.
>
>Frequently used routines reside in the start up program, in a procedure file, or in separate files if they are large. Setup code for reports resides right in menu snippets. There are also a lot of calculation routines in the procedure section of the forms that need those calculations.
>
>Lastly, I use global variables to hold some frequently used values that I do not wish to fish repeatedly from the parameter table.
>
>I wish to follow good OOP practice. A friend suggested three main objects: oApp, oBiz, and oDS (for data services). While these are good classifications those objects will quickly become bloated and it will be hard to find things.
>
>I am thinking of adding the following objects:
>
>1) oCalc. To hold calculation methods. One method, for example, may calculate accrued vacation.
>
>2) oReports. Its methods would setup reports as well as call the report itself.
>
>3) oValues or something like that to hold a bunch of values that I need quick access to. These are awfully much like global variables, but at least they are loaded upon object instantiation and therefore are more standalone.
>
>What are natural subcategories that people use ?
>
>TIA,
>
>Alex