Post History

<h2>Mistakes</h2>

Human programmers make mistakes.  The more the compiler can disallow actions that are unambiguously mistakes, the better.  Strong type checking and encapsulation are probably the two most common means a compiler can "wall off" the human programmer from things they shouldn't be allowed to do.

In your ring buffer (FIFO) example, an application that uses the FIFO should only be allowed to put and get data into and out of the FIFO.  There is no need to an application to alter internal FIFO state.  Any attempt to do so would be a mistake.  Not making that state available to the application eliminates the possibility of such a mistake.

<h2>Levels of abstraction</h2>

Another somewhat orthogonal argument is that each level of the software should only know and care about what is appropriate for that level.  The application should not care how a FIFO is implemented, only be able to access it via a well-defined set of actions that are appropriate for applications to perform.

This concept allows for easier maintenance and ongoing modification of the code.  If a better way of implementing a FIFO comes along, the FIFO routines can be re-written in isolation as long as the interface to the application remains the same.  Therefore, the smaller and more limited that interface is, the more likely a new FIFO architecture can be implemented transparently to the rest of the software.

Note that some modifications of underlying functions, like FIFOs, might not be because something better comes along.  The modification might be to keep more statistics, to aid in debugging or trapping specific conditions, etc.

Another way to look this is that the application interface is a promise of what will always be kept constant.  Once you make a public promise, you have to assume someone somewhere out there is relying on it.  The less you promise, the more you retain future flexibility to change things underneath the publicly-visible interface.  Therefore promise only what the application actually needs.