Information hiding

One of the basic principles of software development is information hiding. People agree that it’s desirable, but may not realize they have different ideas of what it means. And when done poorly, well-meaning attempts to make software more maintainable backfire. Leo Brodie cautions

… we should clarify. From what, or whom, are we hiding information?

[T]raditional languages … bend over backwards to ensure that modules hide internal routines and data structures from other modules. The goal is to achieve module independence (a minimum coupling). The fear seems to be that modules strive to attack each other like alien antibodies. Or else, that evil bands of marauding modules are out to clobber the precious family data structures.

This is not what we’re concerned about. The purpose of hiding information, as we mean it, is simply to minimize the effects of a possible design-change by localizing things that might change within each component.

Quote from Thinking Forth. Emphasis added.

 

8 thoughts on “Information hiding

  1. I read Thinking Forth when it was first published in 1984, and it still stands as one of the best books available for an introduction to software development.

  2. One great side effect of information hiding is to prevent undocumented use of a module by another module.

    I recently met with an important customer of ours (IBM) that is striving with thousands of interdependent applications and online services. These are running on thousands of servers. When there is an incident requiring the reboot of a server they are incapable of predicting which online service will be affected, because their developers have cut so many corners in calling other apps from within an app. These developers are often bypassing documented apis which leads to unknown dependencies.

    If each of their apps and services was hiding information beside documented apis then this customer ability to react to issues would be much greater now.

  3. That’s consistent with Brodie’s view, or maybe orthogonal. Putting stuff together that needs to be modified or deployed together would help the situation you described.

    I’m not condoning using undocumented features. Generally not a good idea. But the information must not have been effectively hidden since they were able to use these undocumented features.

  4. Any experienced developer will tell you, the most common reasons for using undocumented interfaces (API/ABI, unofficial op codes, etc.) are primarily; the published or available official interface does not actually include the necessary information that is needed to complete the task, so developers are pressured to implement “something that works” rather than force managers / architects confront the broken interfaces through official channels.

    The second reason is as a means of performance optimization, which may be necessary at the time of implementation, in order to make performance reasonable. Managers and customers won’t accept a product that takes “too long” to do the task, even if the objection is a purely subjective one. Again developers tend to find it easier / quicker / feasible within their domain of control to break the official API/ABI in order to achieve a performance improvement, rather than negotiate with whomever is responsible for the “other” module(s), to generate a suitable change in that interface.

    A variant of this second form was perhaps best illustrated back in the 1990s when Microsoft’s Office suite development team were to found have requested access to undocumented Microsoft Windows features (from the Operating Systems development team) to give their new versions of Office applications a performance advantage over their business software competitors (Corel, Word Perfect, Lotus, dBase, etc.) when running under newer versions of MS-Windows. This came to light in the late 1980s to mid-1990s during anti-trust / anti-competition investigations by either the US FTC or DoJ.

  5. They sound pretty much the same thing to me, without proper encapsulation, there will be someone trying to hack with the internal structure of another module. This is especially so with large project and long time span, where modularization is ulmost important.

  6. “The second reason is as a means of performance optimization”

    Indeed. Back in the ’90s, I was writing optimization algorithms for telecom networks. My first encounter with object-oriented design led to some surreal conversations with my software design team. They (quite correctly) pointed out that the data structure I wanted to build broke all of the rules of object design. I (quite correctly) pointed out that the optimization would run for days instead of minutes if they didn’t hand it the world and let it hand back the optimized world.

    More recently, attempts by the military to develop portable software-defined radio waveforms have all stumbled over the conflict between what makes a waveform portable (i.e. information hiding) and what makes it useful (i.e. real-time performance).

  7. Huh. “Information hiding.” I can tell you a thing or two about about that. Listen up.

    Seems like every time I build an instrument around a new sensor, what comes out looks like pure noise, though I know the information is hiding in there, somewhere.

    So I open the chest of sacred statistics and cast spells of PCA at the noise, stripping it away, until the information is finally forced from hiding.

    Only by that time the sample queue has refilled, hiding it all over again.

    The only thing worse than hidden information is obsolete information.

  8. I like this take on information hiding in this humorous paper on INTERCAL http://catb.org/esr/intercal/paper.html

    But I’m not here to talk about eschatology, I’m here to talk about modularity and abstraction. Well, believe me, you couldn’t have designed a language more abstract than INTERCAL. To begin with, one of the most important aspects of abstraction is information hiding. Information hiding is a time honoured tradition of computer programmers, although sometimes it goes by its other name, “job security”. The idea is to make your code as obscure as possible, hiding any possible information, so your employer couldn’t fire you and hire some junior birdman mailboy to maintain your code. INTERCAL doesn’t only hide information it actively distorts it. For example, the easiest way to store the value of 65536 in a 32-bit INTERCAL variable is:

    DO:1<-#0$#256

Comments are closed.