John,

IMHO you have to read the OO theory books and get a grasp of the concept. The theory books are usually not good at putting together concrete examples that I think most people assimilate. I've got an engineering degree so I'm used to using theoretical equations to predict behavior, but it's not the same as taking a sample of something and testing it till it breaks to prove the theory right or wrong.

I think you use whatever public interface that works for your framework. There are definate pluses and minuses with whatever interface you choose. The key point being, once the interface is set, you are stuck with it, unless you enjoy going back and changing already running apps. I sure as heck don't! *s*

I don't have huge problems with direct property access. It's fast, it's clean, it's easy. Access/Assign now give us an easy way of preventing object corruption that required explicit Get/Set methods before. In the end it all boils down to putting apps into production and learning along the way so the next app builds on the knowledge base that's built into the objects. Hopefully the objects become smarter over time.

>One of my goals in starting this thread was to re-examine theory versus what we do day-to-day in VFP. Specifically, I was trying to test the validity of a new design pattern I had worked out that relied on Access/Assign. To my surprise, I have found that direct query of a property is counter to basic OOP theory but almost every language has the constructs to do so.
>
>That may sound trivial but I don't believe it is. If we follow pure OOP as defined by Jacobson, we're gonna get klunky apps because VFP relies on a lot of abstract messaging and interaction which would be an SOB to avoid.
>
>The damn thing is that we're not alone with this dilemma. The other VS tools (especially VB) make compromises. Shoot, MS COM theory is a compromise as it doesn't require inheritance and inheritance is a requirement for OOP.
>
>Maybe we need new Bibles......books on practical OOP for VFP and other VS languages that accept those trade-offs and use them, rather than avoid them. Something that delves deeper into the issue than just a tired old redefinition of inheritance or polymorphism. Something that goes beyond frameworks.