Designing Classes

When you design a class, you decide how a piece of a program will represent an idea and what that piece will be allowed to do. Not every idea needs the same amount of machinery. Some ideas are simple, and some parts of a program must run quickly. For these situations the source describes a particular kind of class called a concrete type. This article explains what a concrete type is, how to decide when it is the right choice, and why the designer must also think about what happens when an object of the class is copied.

Imagine you have written a class, and someone creates an object of that class. Then they create a second object that starts out as a copy of the first. What should that second object be? The answer is not automatic. It depends on what the class represents and on what the designer decided copying should mean. The behavior of an object when it is copied is called its copy semantics, and deciding on it is part of designing the class, not an afterthought to handle once the class is finished.

The working rule is this: whenever you design a class, ask whether and how an object of that class might be copied. Many classes never need special thought here, because the default way of copying is correct for them. Others need a deliberate choice, and getting that choice wrong can produce objects that behave incorrectly after they are copied. The rest of this article follows that question from the default behavior to the cases where the default does not fit.

The most common default copy behavior is memberwise copy. In a memberwise copy, each member of the original object is copied to the new object. The new object is built by going through the original's members one at a time and giving each one a counterpart in the copy. The definition is short, so it helps to trace a concrete case.

Read the diagram from left to right. Before the copy, the original holds two members. After the copy, the original still holds its members, and the new object holds a counterpart for each one. The arrows show which member supplied each value. The new object is built from the members of the original, not from the original object as a whole.

The word simplest is the key to this definition. A concrete type is not defined by a special feature that sets it apart from other classes. Instead, it is defined by sitting at the simple end of the range of classes you could write. When you compare it with a more complicated class, the concrete type asks less of the reader and of the program. That is why the source treats it as the natural starting point when a concept is simple.

The source also gives a preference order. Where it is applicable, prefer a concrete type over more complicated classes and over plain data structures. When you shape a piece of a program, you therefore have three options to weigh: a concrete type, a more complicated class, and a plain data structure. The concrete type is the one the source asks you to prefer when it fits.

The source does not present copy semantics as one rule for all classes. It sorts types into groups, and each group leads to a different conclusion about memberwise copy. The three groups are simple concrete types, sophisticated concrete types such as Vector, and abstract types. Before reading the details, compare the three groups side by side in the diagram below.

Notice the wording for each group. For simple concrete types the source says memberwise copy is often the right choice. For sophisticated concrete types such as Vector it says memberwise copy is not the right semantics. For abstract types it says memberwise copy almost never is. Read the three verdicts as a gradient: the more a type relies on more than its plain members, the less memberwise copy fits.

Vector is the source's running example of a type for which memberwise copy is not the right choice. Vector is a container-like type that is more sophisticated than a plain two-member object such as the point above. Before reading on, decide for yourself whether memberwise copy would be the right way to copy a Vector.

The reason becomes visible when you picture a member that refers to storage holding the elements. Suppose a Vector has a member that refers to the storage where its elements live. A memberwise copy copies that member, which means the new Vector receives a reference to the same storage rather than its own storage. The diagram below shows what that produces.

In this picture, the original and the copy both point at one shared storage. If one of them changes an element, the other sees the change, even though the designer may have intended the copy to be independent. This is the failure that memberwise copy produces for sophisticated types. The member-by-member rule did exactly what it says, and that is the problem.

Once you accept that a type such as Vector cannot simply rely on memberwise copy, a natural follow-up question appears: how should a container be copied correctly? The source introduces this as its own topic, so it is treated separately from the general idea of copy semantics. Copy semantics tells you what copying an object should mean. Copying a container raises the further question of what happens to the elements it holds.

Containers are objects whose job is to hold other objects. Because they hold things, the copying question involves more than the container's own members. The source signals that copying containers deserves focused attention under its own heading, and the detailed rules are developed there. For this article, the important point is to recognize the question as separate, so that you do not assume the answer for a container follows automatically from the answer for a simple class.