1.12 Objects: Instances of Classes

1.12 Objects: Instances of Classes

A class describes what a kind of thing is; an object is one specific thing made from that description. A Monster class might define that every monster has a color, a number of eyes, and a name, while each individual monster has its own particular values for those attributes.

Learning Objective 1.12.A.1: Explain the relationship between a class and an object.

Essential Knowledge 1.12.A.1: An object is a specific instance of a class with defined attributes. A class is the formal implementation, or blueprint, of the attributes and behaviors of an object.

Class as a blueprint

A class is a formal blueprint for modeling objects. It identifies the attributes—data that describe an object—and the behaviors—operations that an object can perform—that belong to a particular category.

The blueprint is not one particular monster. It is a general model:

Class-level idea	Monster example
Attribute	color, eyeCount, name
Possible value	"green", $3$, "Gloop"
Behavior	roar, move, or attack
Individual object	One particular monster with its own values

A class lets a programmer describe a category once instead of separately describing every member of that category. If a program models a game containing hundreds of monsters, the Monster class can establish the common structure while each object represents one distinct monster.

Objects and instances

An object is a specific instance of a class. “Instance” means a particular object that belongs to the class and has defined attribute values. Two objects can come from the same class while differing in their attributes.

For example, imagine two objects modeled by the Monster class:

• Monster A: name "Gloop", color "green", eye count `$3$
• Monster B: name "Mira", color "purple", eye count `$1$

Both objects follow the Monster blueprint, so both have the same kinds of attributes. However, they are not the same object: their attribute values describe different individual monsters.

A Java model

In Java, a class can declare the attributes and behaviors that its objects are expected to have. The following declaration models the shared structure of monsters without yet focusing on how a particular object is created or stored:

public class Monster
{
    private String name;
    private String color;
    private int eyeCount;

    public void roar()
    {
        System.out.println(name + " roars!");
    }
}

The class defines three attributes: name, color, and eyeCount. It also defines a roar behavior. The declaration says that monsters have this structure; an individual monster supplies its own attribute values. The keyword private limits direct access to the attributes, but it does not change the central relationship: the class is the blueprint, and an object is a concrete instance of that blueprint.

One blueprint, separate identities

A useful physical analogy is a cookie cutter and the cookies it produces. The cutter establishes the shape, just as the class establishes the available structure. Each cookie is a separate object, even though all cookies share the same general shape.

The analogy has an important limit: object attributes can vary. A Monster class may require every monster to have an eye count, but one object can have $3$ eyes and another can have $1$. Shared structure does not mean shared attribute values.

Misconception check: A class is not an object, and an object is not merely a renamed class.
A class describes a category; an object is one particular member of that category.

Designing a model

When designing a class, ask two questions: What information must each object remember? and What can each object do? For Monster, useful attributes might include name, color, and eyeCount; useful behaviors might include roaring or moving. The answers define a model of the real-world idea that is precise enough for a program.

This directly exercises Computational Thinking Practice 1 — Design Code: deciding what the class should represent and which attributes belong in the model. Writing the class declaration applies Computational Thinking Practice 2 — Develop Code, while tracing two monsters with different values applies Computational Thinking Practice 3 — Analyze Code. Clear names such as eyeCount also support Computational Thinking Practice 4 — Document Code and Computing Systems because the code communicates its model to other programmers.

Class hierarchies

Essential Knowledge 1.12.A.2: A class hierarchy can be developed by putting common attributes and behaviors of related classes into a single class called a superclass. For example, several creature classes might share attributes such as name and color, while a more specific Monster class adds monster-specific features. The key idea is reuse of common structure among related classes.

Retrieval check: If Monster is the class, what makes “Gloop, a green monster with three eyes” an object? Why can another object from the same class have a different color value?
Answer: Gloop is an object because it is one specific instance of the Monster class. The class defines the attribute color, but each object has its own defined value for that attribute.