>>Sure. The idea behind abstraction is that the inner workings of an object should be hidden, and only the necessary interface exposed. It is the idea behind hidden and protected properties and methods. This premise is central to not only VFPs object model but many others as well.
>
>I've learned all this stuff by 'BANG HEAD HERE' method and I can see properties having hidden - protected, but I'm not sure I see the value of having the method code hidden, protected yes???

Are we talking about hidden code or hidden interface? If you use subclasses, you are dealing with hidden code. Is this what you don't see the value in?

If you are questioning the virtue of hidden methods, that's easy. I have a method called HandleConflict in my form update class that handled what happens in case of an update conflict. This method is designed to only be used by two other methods in the class hierarchy, and not to be used at the instance level. IOW, I should never be able to call THISFORM.HandleConflict from another control.

Hidden code is not so cut and dried. VFP was designed so that when using classes, we cannot see the code in the the superclass methods (not without Mr. Levy's tool, Supercls or something similar.) This is a pain when we are still working through and debugging the class design. But when the class is built and tested, we can count on its functionality and should be able to drop an instance on a form, set a property or two, and roll. There is no need to have the class code easily editable any more. This was annoying to me at first, but now that I have an established frameork, I am glad I don't have to look at class code anymore.