Black box programming and modularity

The goal is to provide an accurate description of what a routine does in terms of externally-visible behavior.

That should be all the information someone needs in order to use the routine correctly.

This reduces the information one needs to keep track of - the only time you need to consider the internal details of the routine is when actually implementing it, at all other times you (or any other developer) need only consider the black box description.

In black box programming, when using a function you don't care how the function is implemented.

With each function there should be a description detailing what the function does in terms of what goes in and what comes out.

In a practical sense, that is very often the only information you will be given about many of the routines you use.

The C libraries are a classic example - you use routines from these libraries all the time, without knowing how they are implemented.

Both the person calling a routine and the programmer who implemented it must be very careful, however.

• The user must be sure they understand the correct format for data used by the routine, and the form in which information will be returned. The user must also be aware of any possible side effects from calling the routine.
• Similarly, the programmer who implements the routine must be careful to exactly describe the data-in, data-out, and side-effects, without cluttering the description with unnecessary facts about the internal operation of the routine.

Flawed blackbox example

1. Doesn't describe side effects:

   int Sum(int aiData[], int iSize)
   /* returns the sum of aiData[0] through aiData[iSize-1] */
   {
      int i;
      for (i = 1; i < iSize; i++) aiData[i] += aiData[i-1];
      return(aiData[iSize-1]);
   }
   

2. Doesn't describe the error handling:

   int GetRange(int lower, int upper)
   /* prompts the user to enter a value in the range
    * lower .. upper and returns that value
    */
   

3. Gives unnecessary internal details:

   void ReverseString(char szInput[], int iSize)
   /* reverses the first iSize characters in the data string
    * by pushing them onto an internal stack, then pops them
    * off the stack overwriting szInput until the stack is empty
    */
   

Benefits of blackbox programming

• if the description is accurate it's all the information the programmer needs to know
• the blackbox description is much easier to grasp, and less of your memory is wasted on details you don't need
• for those maintaining the code, the blackbox description is a clear reminder of the external rules the routine must adhere to

Disadvantages of blackbox programming

• using someone else's blackbox routines you might not get exactly the routine that would be ideal for you
• you might not get peak efficiency - sometimes the way the code is written and the way it is used lead to unfortunate slowdowns

  Example: routines to sort arrays of data

  • one common algorithm is Quicksort: this is very efficient on most data sets, but very slow with data which is almost sorted already
  • another sorting algorithm is Bubblesort: this is very efficient on almost-sorted data, but is very slow with most data sets
  If the user is unaware of these details, they may inadvertently choose a sort routine which is less effective for the kind of input data they typically work with

  i.e. sometimes the implementation does have an impact on performance (though all implementations should give the correct final result)