Information Hiding

Each module encapsulates a few design decisions inside its implementation, and those decisions are not visible in its interface. The opposite, information leakage, is when one design decision is reflected in multiple modules.

Why it Matters

Information hiding is the mechanism that makes modules deep. When a design decision lives in exactly one place, it can change without rippling outward, which directly reduces change amplification and the cognitive load of working across modules.

Signals

• A decision (a file format, an algorithm, a hardware detail) can be changed by editing one module.
• Leakage signal: two modules must change together whenever a single decision changes.
• Temporal decomposition is a common cause: structuring code around the order operations happen (read, then modify, then write) instead of around the knowledge each unit needs, which spreads one decision across stages.

Benefits

Localizes change, shrinks interfaces, and lets modules be understood in isolation. It is the single most important technique for designing deep modules.

Risks

Exposing internals "just in case" (overexposure) leaks information. Designing around workflow/time order rather than knowledge tends to scatter decisions.

Tensions

Hiding information can require slightly more work at a boundary (e.g. recomputing rather than exposing a cached value). The cost is usually worth it, but not always; performance-critical paths sometimes justify controlled leakage.

Examples

A module that owns a file format and exposes only read/write hides the format. If both the reader and a separate writer encode the format independently, the format decision has leaked across two modules.