>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.

Code on the DBC-side [i.e., server-side] is also mimicking backends like SQL-Server and Oracle stored procedures.