One of the things we do when we design software is decide how to separate it into modules. For any given program, there are multiple approaches we can take to do this. And it’s an important decision, because it can have far-reaching effects on our ability to grow and maintain the software.
One thing we can use to steer us in the right direction is a simple question: What will change?
If we know some aspect of our program is going to change, we can put that stuff into its own module and hide the details from the other modules. Then, when the change needs to happen, we only need to update the one module. This is how our choice of modules helps with growth and maintenance of the software.
Of course, we don’t know what’s going to change. But we do tend to have some idea about some things that we think are likely to change. We do our best with the information we have. (And we don’t let the possibility of future change lead us to add complexity or make constraining decisions now.)
This approach to choosing our modules is called “information hiding”.
(Extra credit: Information hiding comes from a fairly readable academic paper by David Parnas, published in 1972. Parnas wrote two programs with the same external interface, using two different approaches to select modules. Then he compared the two programs and concluded that the information hiding approach was better.)
