Understanding Objects, Classes, and Instances

You have already spent several chapters working with classes. A class can hold variables and methods, and you have written subroutines inside classes many times. Objects are built from the same ingredients, so it is natural to wonder how an object differs from the class it came from. Early in a course the difference can seem small. Once a program creates many objects from one class, and creates and discards them while it runs, the difference becomes important. This article traces that difference step by step, so you can reason about your code with confidence.

Most people first hear that objects belong to classes. They picture this relationship the same way they picture a member variable belonging to its class. That picture feels reasonable, but it hides the most useful fact about the relationship. A member variable is part of the class's own definition. An object is a separate thing that the class helps to produce.

The phrase objects belong to classes is a common shorthand, and it is worth being careful with it. The word belong suggests ownership of a part, as when a variable is a piece of its class. What actually happens is construction of a new item. The class is used to construct objects, and each object that results is its own item with its own values.

A class is a blueprint, or factory, used to construct objects. It describes what objects will contain rather than being the objects themselves. Think of a blueprint for a house. The blueprint does not contain a house, and it does not live in a neighborhood. It specifies what the house will have: its rooms, its doors, and where the walls go. Each house built from that blueprint has the same layout, yet each is a separate building that can be painted a different color or furnished differently. A class plays the same role for objects.

The clearest way to see the difference is to compare what exists in the program at a given moment. The class is one description. The objects are several separate items that exist only while the program is running. The diagram below places the single class description beside the objects it produces. Notice that there is one description on the left and many items on the right, and that the arrows show the description being used to build each object.

The source emphasizes that objects are created and destroyed as the program runs. The class, by contrast, is the description that stays in place. You can think of the class as a fixed plan that exists before the program does anything interesting, and the objects as temporary products that appear when the program asks for them and disappear when they are no longer needed. Because of this timing difference, one class can produce many objects over the lifetime of one program, and those objects do not all need to exist at the same moment.

The description inside a class is split into parts. The non-static parts are the ones that matter for building objects. They specify which variables and methods each object will contain. When the source says that the non-static portions of a class describe objects, it means that those portions set out the structure every object created from that class will have. Every object made from the class gets the same set of variables and methods, even though each object holds its own values for them.

The diagram shows three separate objects. Each one contains the same kinds of variables and methods, because the non-static parts of the class specify them. What differs is the values stored in each object's variables. The objects are separate items, so changing the values in one does not change the values in another.

The factory picture is useful because it turns the relationship into a sequence. Each time the program asks the class for a new object, the class uses its description to construct an item with the structure it specifies. The following diagram follows that sequence for two requests. Read it from top to bottom, since each message happens after the one above it.

Both requests use the same description, so both objects have the same structure. The class itself is not consumed by the request. It stays in place, ready to construct another object whenever the program asks. Later, when an object is no longer needed, it can be discarded, which is the other half of the lifecycle the source describes.

The following example is an original illustration written for this article. It is not taken from the source. It uses Java-style syntax to show a class whose non-static variable is set separately for each object. The class is the description, and each call that builds a House produces a separate object.

The source notes that early in a course you may have worked with an object only once, and it seemed to make little difference whether a subroutine was defined with the word static or without it. The distinction matters more once many objects are created. The non-static parts of a class are the ones that determine what each object contains. A member that belongs to the class as a whole is handled differently from a non-static part, so it is worth checking which kind of member you are writing before you rely on it inside many objects.