On Mon, Jun 2, 2008 at 10:50 PM, Russ P. <[EMAIL PROTECTED]> wrote: > On Jun 2, 6:41 am, Carl Banks <[EMAIL PROTECTED]> wrote: > >> You are not realizing that only useful(**) thing about data hiding is >> that some code has access to the data, other code does not. If you >> "hide" data equally from everyone it's just a useless spelling change. > > I think you're missing the point. > > As I see it, the primary value of data hiding is that it provides > useful information on which data and methods are intended for the > client and which are intended for internal use. It's like putting a > front panel on a TV set with the main controls intended for the > viewer.
Here's my two cents. First of all, a TV is a bad analogy compared to reusable software libraries. Really bad analogy. A TV is a horribly complicated device which has to be dumbed down because otherwise it would be to hard to use for ordinary people. A software developers relation to a third party library is more similar to a TV repair man trying to repair a TV than to a random person watching TV. For a repair man, the front panel is just useless and in the way. Oh, and to continue on the TV analogy, one of the reason why a TV is complicated is because its interface is totally different from its implementation. Channels are just a bad abstraction for tuning the receiver to different frequencies and for switching inputs. Merely using a TV doesn't teach you anything about how it actually works. KISS: Keep It Simple Stupid. And it is always simpler to not implement the gunk needed for data hiding than to do it. By keeping things simple you keep your code easy to implement, easy to understand and easy to reuse. Data hiding sacrifices implementation simplicity supposedly to make the interface simpler and to keep backwards compatibility. It allows you to change implementation details without affecting the interface. But do you really want to do that? Consider this silly Java example: class Foo { private int bar; public int getBar() { return bar; } }; Then for some reason you decide that hm, "bar" is not a good attribute name so you change it to "babar". And you can do that without changing the public interface! Woho! So now you have a public getter named "getBar" that returns an attribute named "babar". That's in reality just bad and whoever is maintaining the implementation is going to be annoyed that the getters name doesn't match the attribute name. What would have happened without data hiding? Renaming the public attribute "bar" to "babar" probably cause some grief for someone reusing your library, but you would keep your implementation pure. What about semantic changes? Data hiding doesn't protect you against that, so you'll have to change your interface anyway. The interface for a car hasn't changed much in the last 100 years, but the implementation has. How easy is it to repair a car nowadays compared to 30 years ago? And data hiding as a documentation aid is just a sham. "These methods are public so you can call them, these aren't so hands off!" A reuser of your library *will* want to know what happens on the inside, by trying to make stuff impossible to reach you are just making that kind of information much harder to come by. The better method is to just write proper docstrings that tell the user what the methods do and when they can be called. Another good way to see how useless data hiding is, is to try and unit test a very encapsulated library. You'll see that it is almost impossible to write good unit tests unless you publicly export almost everything in the code. At which point you come to realize that all the data hiding was for naught. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list