C, C++, OCaml, Eiffel, Ada, most assemblers, and the like have facilities for "mandatory information hiding", in which some parts of the program are not accessible to other parts of the program. Textbooks and academic papers on such things often describe their benefits in terms of security, with examples like bank-account objects that must conserve funds in the face of malicious client code.
It's often useful to think about software robustness properties in terms of robustness against malicious attacks, since if a malicious attacker wouldn't be able to violate some robustness property, then no neither can client code that is simply malfunctioning. The benefit of thinking in these terms is that it avoids the necessity to model the possible malfunctions of the client code and their probabilities, a cognitive task generally so difficult as to be infeasible a priori. And there have been various systems that use language-level information-hiding facilities to enforce security properties --- E is the best-developed example, but Java has tried to do this as well. However, though, it is not necessary to resort to arguments about robustness in the face of partial failure or malicious attack to justify the introduction of these mechanisms. The benefit they have given me from time to time is quite different. It's well known that most of the time spent on programming is spent on "maintenance", by which we mean modifying software somebody is already using, usually to add new features; and that most of the time spent on "maintenance" is spent understanding the existing code so as to be able to make modifications that won't break other things and won't be hard to understand again later. Much of this activity consists of understanding what parts of the code must be changed together, and how they must be changed to ensure that the code continues working. The advantage of mandatory information hiding is that this task becomes simpler. If I'm changing the semantics of a private method in C++, I need only look within that method's class for calls to the method; I don't need to look anywhere else. I have occasionally wished for this feature in Perl on a 100 000-line project. This understanding of facilities for mandatory information hiding suggests some differences over the standard understanding: - The facility is still important even when you don't have malicious code running in your process space, and even in languages like C++ or Python where there is no really effective access control. - The point of the facility is not to keep information from your team members, although indeed some of its earliest proponents thought it was. Therefore, changing a method from private to public because you need access to it from somewhere else is not a sin. (At least, not for this reason.)
