Class vs Object

A class is a description: the set of fields an instance will have, the methods it will answer to, and the rules the compiler enforces about how those may be used. It is not data itself, and there is exactly one copy of it per class loader for a given program. An object is a runtime instance of that description, and each one carries its own copy of the instance state.

The runtime keeps the class as metadata, including its method bodies and the layout of its fields, and it uses that metadata to allocate and initialise objects. Creating an object allocates space for the instance fields, runs the initialisation the class specifies, and hands back a reference. The reference is not the object; it is a value that points at one.

Two practical consequences follow from that. First, the class is where behaviour is written once and shared by every instance, while the instance fields are where the differences live. Second, a reference can be copied freely without copying the object, which is exactly why two variables can end up pointing at the same mutable state and why you have to be careful about who is allowed to change it.

A good closing line for an interview: the class is the type and its rules, the object is one living thing that follows those rules, and the reference is your handle on it.

Three objects are created: one front wheel, one rear wheel, and one car. The references front, rear and car are not objects, they are values that point at objects. The car holds references to the same two wheel objects that the local variables point at, so nothing is copied when the car is constructed.

public class Main {
    public static void main(String[] args) {
        Wheel front = new Wheel();
        Wheel rear = new Wheel();
        Car car = new Car(front, rear);
        System.out.println(car);
        front.tyre = "alloy";
        System.out.println(car);
    }
}

class Wheel {
    String tyre = "steel";
}

class Car {
    private final Wheel front;
    private final Wheel rear;
    Car(Wheel front, Wheel rear) { this.front = front; this.rear = rear; }
    public String toString() {
        return "car(" + front.tyre + "," + rear.tyre + ")";
    }
}

That sharing is visible in the output. The first line prints car(steel,steel). After front.tyre is set to alloy, the second line prints car(alloy,steel): the car observed the change because it is looking at the same wheel object, not at a snapshot.

The interesting wrinkle is that the wheel field is package-private, so the main method can reach in and change it. The car holds the wheel as a reference and trusts that nobody else mutates it. That assumption is exactly what encapsulation is designed to remove: if the tyre field were private with a method to change it, the change would still be visible, but it would at least pass through a place where rules could be enforced.

The general lesson is that passing an object around shares it. If you want an independent copy, you have to make one deliberately, and that is the shallow versus deep copy question.

An object is a concrete, living instance created from that blueprint. When you write new Wheel(), the runtime allocates space for that instance's fields, gives them their starting values, and returns a reference you can hold. The class describes what every wheel will have; the object is one particular wheel, with its own tyre value that changes independently of every other wheel.

The blueprint metaphor is useful but slightly dangerous, because it hides the fact that objects are not passive shapes. They carry behaviour as well as state, and they can hold references to other objects, so what you really get is a small network of collaborating things rather than a set of isolated shapes.

Two objects created from the same class share the same behaviour and the same code, but not the same state. Changing one wheel's tyre leaves every other wheel untouched. That separation is the reason classes are the unit of reuse without classes becoming a shared mutable mess.