Abstract Classes and Interfaces

Every piece of data a program works with has a type. The type tells the language what kind of thing the data is and which operations make sense on it. A language comes with some types already built in, but real programs usually model ideas that the language designers could not predict: an invoice, a sensor reading, a game character, a network connection. If a program can only use the built-in types, it has to describe these ideas with loose collections of plain values, and the code drifts away from the problem it is trying to solve.

This article follows one idea through the chapter. We will watch what a user-defined type contains, how the three families of user-defined type differ, and how they connect to one another. Keep an eye on two goals as you read: abstraction and resource management.

The idea is more than naming a new kind of thing. A user-defined type bundles data together with the operations that are allowed on that data. The rest of the program can then treat the new type as one meaningful unit instead of a loose collection of values. Think of the bundle as having two parts: the data it holds, and the operations the outside world may perform on that data.

C++ supports two broad goals in this part of the course. The first is abstraction. Abstraction hides the messy details of how something works behind a simpler interface, so that a user of a type can focus on what it does rather than how it does it. The second is resource management. Resource management handles things a program must acquire and later give back, such as memory or other limited items, in a disciplined way.

User-defined types are the main tool that brings these goals together. The type decides what the outside world can see and do. It can also control how the resources behind it are handled. So when you read about the three families below, ask two questions about each one: how does it hide detail, and how does it handle the resources it depends on?

This overview introduces three families of user-defined type: concrete classes, abstract classes, and class hierarchies. It does not work through each one in full detail. Instead, it gives the basic properties of each, the general implementation techniques behind them, and the language features that support them. The three families are not separate islands. All of them belong under the umbrella of user-defined types, and a class hierarchy is the structure that ties several related types together.

The source describes abstract classes as describing what related types must provide. To see this in a concrete setting, follow a small family of types that share a common idea. The names Shape, Circle, and Square below are generated for teaching; they are not taken from the source, but they show how the pieces of a class hierarchy fit together.

Concrete and abstract classes are easiest to tell apart by asking one question: can you create a finished object straight from this type? A concrete class passes this test. An abstract class does not. Concrete classes are usable directly, while abstract classes describe what related types must provide. The table compares the two on the points this overview covers.