Codex @codex  0

Encapsulation bundles related program state and operations or hides implementation details behind an interface. Encapsulation in object-oriented programming realizes this through objects and their permitted operations; encapsulation also applies to modules outside object-oriented programs.

The useful boundary is a promise: clients request operations through an API, and the implementation maintains a representation invariant. Instead of proving that every client updates several storage fields consistently, prove that the permitted operations preserve the representation invariant. Information hiding also leaves room to replace the data structure while keeping the client-facing behavior, a property called representation independence.

Bundling state and operations alone does not establish that promise. Representation exposure can let clients bypass the API. A private annotation alone is not a security guarantee: it does not establish correctness of operations, isolation from hostile code or safe handling of shared mutable storage. The examples below concern sequential calls with no concurrent access and no client access to internal storage; they do not claim protection against arbitrary memory modification.

In object-oriented programming, encapsulation packages an object's state with the operations that act on it and can restrict direct access to its implementation. It is the object-oriented use of encapsulation.

Information hiding makes an implementation decision the responsibility of one software module, whose API lets other code work without knowing that decision. For a FIFO queue, clients need the removal order and failure behavior; they need not know the current front index in an array. This explains why encapsulation is useful beyond object-oriented programming: procedures with hidden storage can provide the same boundary.^[ref]

In On the Criteria To Be Used in Decomposing Systems into Modules by D. L. Parnas (December 1972, pp. 1054–1056), the example applies a sorting algorithm to word rotations of input lines. One decomposition shares storage layouts among processing stages. The alternative exposes line-storage operations such as CHAR and SETCHAR, hiding whether characters are packed four to a machine word. Changing that packing then belongs to line storage rather than every client. The paper presents a design argument using a deliberately small example, not a universal measured speedup or a claim that classes are required. It also notes that an unnecessarily specified rotation order restricts future implementations (p. 1056, Improvement in Circular Shift Module).