Pointers to Objects in Collections

Imagine you are building a drawing program. Users can place circles, squares, and triangles on a canvas, and the program needs to keep all of them in one collection. Once the figures are stored, a practical question follows: how do you write a single function that processes every item in that collection, without writing a separate function for each kind of figure?

The answer depends on a design decision about the base concept that all those figures share. If every figure is a Shape, the real question becomes what a Shape itself should be. This article approaches that question from the side of design: what kind of class Shape should be, and what it can honestly promise to the functions that use it.

Before deciding what goes into the collection, it helps to see what the collection cannot hold. The figures in the drawing program are different concrete types. A circle, a square, and a triangle are not the same kind of value, so the collection cannot treat the figures themselves as one uniform kind of item.

The solution is to make the collection uniform at the level of the pointer. Each pointer refers to some concrete figure, whether that figure is a circle, a square, or a triangle. The collection itself is uniform because every element is a pointer to a Shape. The diagram below shows the relationship between the collection, its pointers, and the objects they refer to.

Read the diagram from top to bottom. The collection is the single container. Each pointer in the middle row is a stored element. Each pointer leads down to one concrete figure. The collection never needs to know which figure sits at the bottom of a given pointer; it only needs each element to be a pointer to a Shape.

Shape is the standard example. There is no such thing as a generic shape sitting in a drawing: every real shape is a particular kind of shape, such as a circle or a square. So Shape works as an abstract class. Its job is to name the common idea of a shape and to serve as the common base that the specific figures build on.

Notice the wording of the source definition. It does not say an abstract class has no purpose. It says it is not meant to be instantiated on its own. That distinction matters: a Shape can be the type that every figure is described by, even though no drawing ever contains a plain Shape that is nothing in particular.

In the inheritance hierarchy, Shape sits above the concrete figures. Circle, square, and triangle are derived from it. The diagram shows the family tree. Notice what it does not show: the fields inside each figure. Each derived class brings its own details, and the abstract base sits above them as the shared name and shared contract.

The contrast in this tree is intentional. The hierarchy is a relationship between kinds, so Shape is the general kind and the figures are specific kinds beneath it. The stored data stays specific to each kind. Shape is the only class in the tree that cannot be created as an object, while Circle, Square, and Triangle are the figures a drawing actually contains.

It is tempting to think of a base class as a template that fills in fields for every subclass. A circle has a radius, a square has a side length, and a triangle has three sides, so one might expect a common base to hold a shared set of numbers. The abstract class idea runs the other way. Because the representations differ so much, the base is valuable for what it allows callers to do, not for what it stores.

The source states the point directly: as far as representation is concerned, nothing except the location of the pointer to the vtbl is common for every Shape. In other words, the Shape part of each object carries no common fields that all shapes must store in the same way. What the derived classes share is the interface through which they are used, not a common layout of stored values.

This explains why the base can be abstract without being a container. A circle needs a radius, a square needs a side length, and a triangle needs three sides. Those requirements are different, so the derived classes keep their own stored details. The one thing the source says is common to every Shape is the location of the pointer to the vtbl, and that is part of how each object is organized rather than a field the programmer designs.

The difference between storing figures by value and storing pointers to them is the reason the design works. The table below compares the two approaches using only the ideas the source supports.

The contrast answers the question of why storing pointers keeps the behavior of the derived classes available. Each pointer still refers to a concrete figure, so the figure's own details remain where they belong, while the collection stays uniform at the level of Shape.