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]
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
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). Articles by others on the same topic
Information hiding is a design principle in software engineering that emphasizes the separation of a system's interface from its implementation details. The main goal of information hiding is to reduce system complexity and improve maintainability by limiting the exposure of internal workings to outside components or users. Key aspects of information hiding include: 1. **Encapsulation**: By encapsulating data and methods within classes or modules, details of implementation are hidden from other parts of the program.