>I created a class to process 'Work Order Items'. Nothing special: quantity, item, price and total.
>
>My class has a property for the alias, so it can work with several different alias. The class assumes that the field names are going to be the SAME in any alias that I use. This make the class very limited. Not as reusable as I would like.
>
>Now, lets make the field names dynamic as well. I added 4 more properties to let the programmer specify the field names. Now everything needs to be defined in the properties and I lost all the visual stuff from VFP.
>
>Now, to get the item name and item price I need to look another tables. Hum, here we have the same problem. The look up tables needs to have the same structure for all the instances that pretend to use this class (or I need to make everything a property to let VFP redirect at run time.)
>
>Shouldn't I been working with objects and forget about the underlying structure (tables structures)? After all I can just add Load and Save methods to my classes and put there the table-specific code. That will make me an truly-OO guy. Well that also will make me lost a lot of the VFP database capabilities at some points (the code executed between the Load and Save methods - and there will be a lot of code.)
>
>So, I have 2 options:
> * Be truly-OO and lost VFP database capabilities
> * Use VFP database capabilities and forget about reusability (true reusability)
>
>
>Which one is the better? Why?


The beauty of OO is that you can have your cake and eat it.

IMHO, the best way forward here is to use two objects. One to handle things at the Business rules level, giving you true OO data, then another to handle the specifics of low level data management.

The business level object can process data in a generic fashion, referring to the low-level object whenever physical data access is required.

The low-level object can then be subclassed for whatever physical data storage is being used (VFP, SQL Server, etc.)