Advantages of the Information Hiding Principle

As propounded by Parnas, the information-hiding principle states that detailed implementation decisions (e.g. data structures and algorithms) should be hidden in modules which have purely procedural interfaces. In this way the implementation details can easily be changed without affecting client modules.

A commonly used, but very trivial, example is a first-in first-out (FIFO) queue, with interface methods to insert an element at the back of the queue, to remove the first element from the queue, to return the first element without removing it, to enquire about the current length of the queue:

A Simple Information Hiding Module - A FIFO Queue

If client modules do not have direct access to the internal implementation details (e.g. the structure of the queue or the elements on the queue) a queue can be implemented as an array or as a linked list, etc. without the client modules needing to be aware of this (or of subsequent implementation changes).

A rigorous application of the information hiding principle has a number of further advantages, including the following:

  • It can aid (and speed up) the specification of large systems, if the modules are all rigorously based on information-hiding principle.
  • It can considerably reduce the level of communication necessary between implementers of different modules.
  • Individual modules can be tested and debugged independently of each other.
  • Synchronisation of shared data structures is simplified, because each major data structure is held in a separate module, together with all the routines which access it.
  • Understanding a system module by module (and therefore maintaining, optimising, extending and adapting a system) is easier, because for each module the related code and data definitions are held together.

This technique is vastly superior to the typical flow of control method of designing large systems, whereby major data structures are often free-standing entities which are accessed from many different code modules. For example an operating system might have a central table for storing information about all the input-output devices. If this can be accessed by many different modules, such as device drivers, spooling modules, device allocation modules, the virtual memory system and the file system, making a change to its design can have disastrous results, because all the programs which access it have to be checked to see whether/how the changes affect them. And it is very easy to overlook something!