Abstract Classes and Pure Virtual Functions

Most code you write eventually has to accept data whose exact kind is decided somewhere else. A function may receive a container, a shape, or a stream without knowing which concrete class was used to build it. An abstract class interface is the tool that makes this possible. It defines the operations that callers may rely on, and code written against it does not need to know which implementation supplies them.

This article follows one small function written in that style. The function is called use(), and its parameter is a Container. The goal is to read it the way a careful debugger would: first by asking what the function is allowed to depend on, and only then by asking what happens when it runs. Keep that order in mind throughout, because it is the fastest way to find a fault in interface-based code.

Look at the parameter type first. The function asks for a Container, not for a particular class with a particular name. Everything the body does is phrased in terms of what a Container can do: report how many elements it holds, and return the element at a given position. Nothing in the body mentions how those elements are stored, which class is handling the request, or what memory layout sits underneath.

The function depends on exactly two operations of its parameter. The first is a size query, used once to fix the loop bound. The second is indexed access, used once per loop iteration to fetch and print an element. The loop itself is ordinary counting code. Its only link to the outside world is through those two operations.

This narrow dependence is the whole point. If the function needs only these two operations, then any type that provides them can be handed to it. The function does not need to know which of several possible classes it is working with, because the names it uses are resolved through the interface rather than through a specific implementation.

The diagram shows the three parts of the design. The function sits on one side and depends only on the interface. The interface is the stable point in the middle. The concrete classes sit on the other side, and each provides the operations the interface names. The labels for the concrete classes are generic placeholders, since the source describes the idea of a variety of classes without naming any particular ones.

This is why use() works with any class supplying a size query and indexed access. The function was written against the interface, so the interface is what makes it reusable. An abstract class is the place where such an interface is declared, and pure virtual functions are the operations that concrete subclasses must supply. The source does not give the declaration syntax, so the important idea to take from this section is the division of responsibility: the interface states what callers may rely on, and the implementation decides how those operations are carried out.

When use() invokes an operation, the call is made through the interface, but something concrete has to answer it. The source puts this precisely: when behavior diverges from expectation, inspect the interface calls and the object that answers them, since the calling function itself names no concrete class. The calling code is never the place where the answer is decided.

Read the sequence as a conversation between three actors. The caller only ever talks about operations on the interface. The concrete object is the one whose behavior actually produces each returned value. A surprising result therefore has exactly two possible origins: the operation as use() requested it, or the implementation that answered it.

Suppose the run does not match your prediction. The function's own text cannot introduce a difference by naming a different class, because it names none. So the search can be narrowed quickly. Use this ordering as a checklist, since the function body has only two interface touchpoints.