Interfaces and Implementations

Imagine a program that started as a single source file of a few hundred lines. Over time it grows until that one long file is hard to read, hard to change, and slow to rebuild after every small edit. A common response is to split the work into several pieces, each responsible for one part of the job. Each piece can then be read, reasoned about, and changed with less worry about the others. This is the basic idea behind modularity: a program is organized as a collection of modules that each have a clear purpose and a clear boundary.

Splitting code into pieces is only half of the story. The benefit becomes real when those pieces can also be compiled on their own. That practice is called separate compilation, and it is what this article focuses on. The key question is how two pieces can depend on each other in a controlled way, so that one can be built without rebuilding the other.

Consider three files. Vector.h holds the information that describes the Vector interface: what a Vector offers and how other code may call it. The file user.cpp contains code that makes use of a Vector. The file Vector.cpp contains the code that carries out the Vector work. Both user.cpp and Vector.cpp rely on the same interface information, and that shared information lives in Vector.h.

The diagram shows the key structure. Both source files point toward Vector.h, and neither points toward the other. In other words, user.cpp and Vector.cpp share the interface but are otherwise independent of one another. The shared header is the only thing that ties them together, and that is exactly what makes it possible to treat them as separate units of compilation.

The word independent carries the weight of that claim. If user.cpp and Vector.cpp were tangled together, with each reaching into the internal details of the other, then neither could be handled without the other. Keeping the link limited to the shared interface means each file can be handled by itself, and the work of building the program can be divided accordingly.

The source describes a recommended approach with three parts, and the order matters. First, the designer should maximize modularity, meaning the program should be divided into pieces that are as independent as sensible. Second, that modularity should be represented logically through the features the language provides, so the boundaries exist in the design and are checked by the language. Third, the modularity should be exploited physically through files, so that each logical piece lives in a file that can be compiled separately.

Logical structure comes first because it determines where the boundaries belong. Language features then express those boundaries in a form the compiler can check. Only after that does it make sense to map the pieces onto files, which is the step that makes separate compilation possible in practice. Reversing the order tends to produce files that were split by convenience rather than by purpose, which is exactly the situation the approach is meant to avoid.

A caller of a square root routine needs to know what to pass in and what comes back. It does not need to be told every step taken to compute the answer. Thinking of the two as different things lets you reason about one without reopening the other. Code that uses a part depends only on its interface, and the interface is the agreed boundary. The implementation sits behind that boundary and can change as long as the interface stays the same.

C++ has a direct way to write down an interface: the declaration. A declaration gives everything needed to use a function or a type, while leaving out the body that does the actual work. Consider the declaration of the square root function, written as double sqrt(double); Read this line in pieces, as the anatomy below shows.

The first double is the return type, the kind of value the function gives back. The name sqrt identifies the function. The parenthesized double is the parameter type, the kind of value a caller must supply. The trailing semicolon ends the declaration. Nothing in this line says how the square root is computed, and that omission is the point: a caller can use sqrt correctly from this line alone.

Functions are not the only thing that gets a declaration. A user-defined type, such as a class, can also be described by one. C++ supports user-defined types, and classes are the main example. Once a type like Vector is declared, the rest of the program can treat it as a new kind of value, one that it can create, index, and ask for its size. The class declaration is therefore an interface for a type, in the same way a function declaration is an interface for a function.

A program that uses Vector only through the declaration depends on the operations it names, such as creating a Vector, indexing it, and asking for its size. The way elem and sz are arranged internally is part of the implementation, and it is the piece that can be revised while callers keep working. Reading the public part of a class declaration is therefore reading the agreed boundary, and reading the private part tells you what the boundary is protecting.

Suppose a call in user.cpp returns a value that is not what you expected. Because the caller relies only on the interface, the first place to look is the declaration that the call must match. The declaration fixes the number and types of the inputs a caller supplies and the type of value that comes back. A mismatch between what the call supplies or expects and what the declaration states is a likely place to find the cause.