Objects versus Classes

The Blueprint and the Instance

The relationship between a class and an object is analogous to a blueprint and a house:

• A class is the blueprint — it defines the structure (fields) and capabilities (methods) that objects will have, but it is not itself a usable entity. It describes what every instance will look like.
• An object is a concrete instance — it is built from the blueprint, occupies actual memory, and holds specific values for its fields. There can be many objects built from one class.

In programming terms: a class is a type, and an object is a value of that type. You can declare a variable of type String and assign it the value "hello". String is the class; "hello" is the object.

Creating Objects with new

Objects are created at runtime using the new keyword:

Point p = new Point(3, 4);

The new operator performs three actions:

1. Allocates memory on the heap for the object’s fields
2. Calls the constructor to initialise those fields to the desired values
3. Returns a reference to the newly created object

The returned reference is what gets stored in the variable p. The object itself lives on the heap; p is just a handle that lets us reach it.

Any number of objects can be created from a single class, each with its own copy of the instance fields:

Point a = new Point(1, 2);
Point b = new Point(5, 7);
Point c = new Point(0, 0);

a, b, and c are three distinct objects, each with its own x and y values. Changing a.x does not affect b.x.

The Box-and-Arrow Model

A useful mental model for reasoning about Java memory:

• A variable is a box. For a primitive type, the box holds the value itself. For a reference type, the box holds an arrow (reference) pointing to a heap object.
• The heap object is a separate region of memory containing the object’s fields (which may themselves be boxes with values or arrows).

When you assign one variable to another:

• For primitives, the value is copied. The two variables are independent.
• For references, the arrow is copied. Both variables now point to the same object (aliasing).

int a = 5;
int b = a;        // b gets a copy of the value 5
b = 10;           // a is still 5 — independent

Point p1 = new Point(3, 4);
Point p2 = p1;    // p2 gets a copy of the reference — same object
p2.x = 10;        // p1.x is now also 10 — aliased

Terminology

The course uses “object” and “instance” interchangeably. Both refer to a concrete entity created by new that belongs to a class. “Object” is the more common term; “instance” emphasises the relationship to the class (“this object is an instance of Point”).

Similarly, “fields,” “instance variables,” “attributes,” and “member variables” all refer to the variables declared inside a class that hold an object’s state. The course primarily uses “fields.”

Class vs Object Summary

Class	Object
A blueprint, template, or type	A concrete instance or value
Exists at compile time (and as a Class object at runtime)	Created at runtime with new
Defines fields and methods; has no values for instance fields	Holds specific values for instance fields
One class per definition	Zero or more objects per class
Static members belong to the class	Instance members belong to an object
Written once in source code	Created as needed during execution

Reflection: The Class as a Runtime Object

It is worth noting that the JVM represents classes themselves as objects of type Class. When you write obj.getClass(), you get a Class object that describes the class of obj. This is an advanced topic, but it reinforces the idea that even classes are reified in the JVM. For the purposes of the Part IA course, think of the class as the compile-time description and the object as the runtime entity.