Information hiding
= Information hiding
<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 (computer programming)> is useful beyond <object-oriented programming>: procedures with hidden storage can provide the same boundary.<On the Criteria To Be Used in Decomposing Systems into Modules by D. L. Parnas>[Parnas, pp. 1054 and 1056, What Is Modularization? and The Criteria: responsibility assignments and hidden design decisions]{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).