>>
>> I think what you are missing is that if the classes are designed properly, there is no need to determine at this early stage what
>database it will be implement
>>
>> If you want to get generic, you could design the object model on a piece of paper without even knowing what you're going to be implementing
>it on. It is kindof
>>
>> Remember, think in general terms. Then when the object model is well under way, you can get more specific and start modeling the design on
>that particular impl
>>
>> Thanks for the advise,
>> Greg
>
>Greg,
>
>Under the circumstances, it should be me thanking you...
>
>You are saying that it _can_ make sense to analyse and design OO, even
>if your programming environment is not.
>
>Refreshing!
>
>Marc


What I am saying is that in a hybrid Object Oriented environment, whether it is Delphi, C++, or VFP, methods are methods and properties are properties. If you design an object model based on only these elements, your design should map to any of these systems in a generic way, given you designed them in a generic way until they need to be implemeted (coded).

What you need to realize is how a (for instance) customer class is modeled to the business app being written first whether through user cases or whatever, then later, when the class works on paper, map it to FoxPro, C++, Delphi, etc. I'm striving just to learn the concepts, though.

I'm not here to argue, just to learn ,as I don't have the answers, I am still learning. It's nice to read opinions, we will form our own judgements to arrive to a solution.

Greg