Frederico,

Those are good questions, and I'm not the one to answer them. I too have been confronted with the problems that arise when you try to apply accademic OO inspired solution to business problems. I have found that data storage is one of the problems, but visual screen drawing is another.

The fact that what is available in those 2 areas "cuts" right trough the classes we would otherwise have come up with, limits the advantages and the payback on the work that make a change of paradigms worthwhile ... in the short term.

So my approach is pragmatic. I will deepen out the class hyerarchy only if reuse is reasonably forseeable, which I'm told is not "programmatically correct". The more domain bound the entity is the less prone it is for OO in this approach.

In rare but relevant occasions have I experienced real payback of implementing OO techniques when complexity was higher than average.

All this being said, I am aware that my point of view is influenced by the projects I usually develop, which are heavily data oriented and small to medium in size. My users are averagely computer litterate (trying to be polite here) and the projects are less than optimally defined, so I need maximum flexibility _after_ deployment.

My 2 BEF.

Marc




>The title for this message covers much ground, but I´m actually trying to work out a design/programming style for VFP which allows for a full object orientation, even though you may work in a Client/Server ambient, with SQL, and wishing to keep VFP's speed.
>
>Has anybody read/seen anything about this?
>
>I've found many articles dealing with the "persistance" problem; how objects can "save" themselves in a RDB such as VFP or SQL Server. But, the kind of programming solutions you use in pure OO languages (such as Smalltalk) don't mesh nicely with SQL or (even less) with a Client/Server situation. For example, working your way through a "Collection", and for each object found, traversing yet another collection, and so on, is what you can usually do in just one SQL statement. And further on, if those objects (and collections) were actually on disk (and accessed only through a Client/Server interface) you would have about a zillion requests to the Server instead of a single SELECT. And I place more trust on my ability to write correct SQL than to work with links, collections, loops, and so on; it´s just a matter of shorter code, and "saying what I want, and no how to get it".
>
>I´m quite convinced that OO is *the* way to go, but I don´t want to lose performance. Academic examples (those which assume that all objects are in memory, and disks simply don´t exist) can afford doing their logic in slow, inefficient ways, since all their data is in memory, anyway. But when you deal with large data sets, and furthermore access them only via Client/Server coding...
>
>So, once more... has anyone seen anything about this kind of programming? Or, even better, done anything of this kind?
>
>Thanks!!