Craig Stuntz’s Weblog

Reg Braithwaite has got me thinking about information hiding. It’s a tenet of modular programming, including OO. But why is information hiding worth bothering with at all?

1. It makes the public interface easier to understand, and therefore the code more readable.
2. It prevents clients of the class from accessing the physical layout of an implementation which is likely to change. By restricting client access to a well-defined and immutable interface, we have some assurance that changing the implementation is less likely to break external code.
3. It prevents clients of the class from breaking the implementation by altering the state of an instance in a way not anticipated or allowed by the class’s designer.
4. For security reasons, some things can’t be shown to the outside world.

For some reason, many discussions of information hiding, such as this Wikipedia article, seem to focus mostly on the second point (allowing change to the implementation without breaking external code). They’re all important issues, although information hiding is not always the best solution to each problem.

Information hiding is not the only way to make a class’s interface more readable, but it is very effective at this. I believe that readability is so important that this reason alone is justification for using information hiding. However, the for hiding information, we would do well to consider whether or not the information should exist in the first place. It’s probably worse to hide cruft than to expose it. Before hiding information for readability, consider whether the information to be hidden is a buried treasure or dust about to be swept under the rug.

The flipside of the second point, preventing the outside world from having dependencies on the internal details of your class, is that the public interface of a class should be, as much as possible, immutable. Hiding the parts of the class that are likely to change is just another way to say that the parts of the class which are not hidden should not change.

The third point, preventing clients from changing the state of a class, seems like a good idea, but it implicitly presumes that the class has mutable state to begin with. It is a non-issue in a stateless class, or a stateful but immutable class.

Security seems like a good reason to hide information, but the hiding is often done poorly, resulting in leaks. Of course, the only foolproof security is not to store this information at all. But if you absolutely must store it, you need to hide it. In this case, the cost of hiding the information well can be quite high.

Funny, I started by talking about information hiding, but with every detail I explore I find myself talking about reducing state (possibly to statelessness) or making it immutable.

Conclusion?

Share This | Email this page to a friend