One of the most important things about good design is modularity: dividing a system into separate pieces so that you can modify one module without the changes rippling all over the system. Early on, it was observed that modules should be arranged around system secrets, each module hiding its secret from the other modules. Then if the secret thing changes, you avoid a ripple effect. One of the most common secrets to hide these days is data structures. An axiom of object-oriented design is that data should always be private, but the idea of hiding data goes far beyond objects. The author discusses guidelines for basic data hiding. His examples all use objects but the arguments apply just as well to non-OO modules. When thinking about data access routines, the author uses two major cases: encapsulating either a single value (such as a person's name) or a collection (such as the line items on an order).