Skip to content

Information Hiding

Every module should hide a design decision that could change, because exposing implementation details creates coupling to those details across the entire system.

Tension Addressed

Abstraction vs. Indirection

Recognizable As

Private implementation with public interface; modules organized around "what might change" rather than "what it does"; encapsulated data structures

Canonical Sources

Parnas, "On the Criteria To Be Used in Decomposing Systems into Modules" (1972)

Transfers To

Software Architecture (service encapsulation), API Design (stable interfaces), Database Design (view abstraction)

Parnas's insight was that module boundaries should be drawn around design decisions likely to change, not around steps in a process. This criterion produces more stable decompositions than functional or data-flow-based approaches.