The Black Box Analogy : Theoretical Explanation
The cause is hidden, but the result is well known.
On daily basis, we consume certain archetypes about programming. Although many reliable sources have accurate pieces of information about efficient programming, I have rarely seen a bit of adequate advice to enrich one’s capability throughout this journey. Though computers are well structured to follow our instructions, they may not have the capacity to read our minds. When we are building a programming project, for instance, it’s essential to write clean, coherent, and readable functions.
The problem occurs when we try to understand every bit of technical ground of what we are dealing with at first sight. Imagine if you had to know every intricate code structure about how your compiler compiles your code. You may be curious about how it works and understand the steps to convert a source code into a machine code, instead you have to accept the fact that sometimes it’s good not to know.
A person who uses a program should not need to know the details of how the program is coded. For instance, imagine how imprecise it would be if you had to know and remember the code for the compiler you use. A program has a job to do, such as compile your program or check the spelling of words in your paper. You need to know what the program’s job is so that you can use the program, but you do not (or at least should not) need to know how the program does its job. A function is like a small program and should be used similarly. A programmer who utilizes a function in a program needs to know what the function does (such as calculate a square root or convert a temperature from degrees Fahrenheit to degrees Celsius), but should not need to know how the function accomplishes its task. This is often referred to as treating the function as a black box. Calling something a black box is a figure of speech intended to obtain the image of a physical device that you know how to use but whose method of operation is a mystery because it is enclosed in a black box and you cannot see inside the box. If a function is well designed, the programmer can use the function as if it were a black box. All the programmer needs to know is that if he or she puts appropriate arguments into the black box, then an appropriate returned value will come out of the black box. Designing a function so that it can be used as a black box is sometimes called information hiding to emphasize that the programmer acts as if the body of the function were hidden from view.
Writing and using functions as if they were black boxes is also called procedural abstraction. When programming, it might make more sense to call it functional abstraction. However, procedure is a more general term than function. Computer scientists use the term procedure for all “function-like” sets of instructions, and so they use the term procedural abstraction. The term abstraction is intended to convey the idea that, when you use a function as a black box, you are abstracting away the details of the code contained in the function body. You can call this technique the black box principle or the principle of procedural abstraction or information hiding. The three terms mean the same thing. Whatever you call this principle, the important point is that you should use it when designing and writing your function definitions.
“Programming isn’t about what you know; it’s about what you can figure out.”
— Chris Pine
Procedural Abstraction
When applied to a function definition, the principle of procedural abstraction means that your function should be written so that it can be used like a black box. This means that the programmer who uses the function should not need to look at the body of the function definition to see how the function works. The function declaration and the accompanying comment should be all the programmer needs to know in order to use the function. To ensure that your function definitions have this important property, you should strictly adhere to the following rules:
- The function declaration comment should tell the programmer any and all conditions that are required of the arguments to the function and should describe the value that is returned by the function when called with these arguments.
- All variables used in the function body should be declared in the function body. (The formal parameters do not need to be declared, because they are listed in the function declaration.)
The principle of procedural abstraction says that functions should be selfcontained modules that are designed separately from the rest of the program. On large programming projects a different programmer may be assigned to write each function. The programmer should choose the most meaningful names he or she can find for formal parameters. The arguments that will be substituted for the formal parameters may well be variables in the main part of the program. These variables should also be given meaningful names, often chosen by someone other than the programmer who writes the function definition. This makes it likely that some or all arguments will have the same names as some of the formal parameters. This is perfectly acceptable. No matter what names are chosen for the variables that will be used as arguments, these names will not produce any confusion with the names used for formal parameters. After all, the functions will use only the values of the arguments. When you use a variable as a function argument, the function takes only the value of the variable and disregards the variable name.
References: Problem Solving with C++, 7th Edition. Walter Savitch, University of California, San Diego.
