classes and objects

the picture

you know how everyone says "a class is a blueprint" and then never shows you the house? here's the house.

think of a cookie cutter (the class) and the cookies (objects). the cutter decides the shape, every cookie gets its own dough (its own fields), and you can bite one cookie without the others noticing. what you're holding in your hand is never the cookie itself, it's a note saying which plate it's on (the reference).

notice what got copied and what didn't. every dog has its own name and age (that's what "instance field" means: one per instance). but birthday() wasn't copied into anybody. the code lives once, in the class, and runs against whichever object you call it on.

a class, piece by piece

class Dog {
    String name;                // fields: the state.
    int age;                    // every Dog gets its own copy
 
    Dog(String name, int age) { // constructor: fills in a fresh object
        this.name = name;
        this.age = age;
    }
 
    void birthday() {           // method: behaviour, shared by every Dog
        age++;                  // short for this.age++
    }
}

field

a variable that belongs to an object. it lives inside the object, on the heap, for as long as the object does.

constructor

the code that runs right after new allocates the object. same name as the class, no return type. the full story is in constructors and init order.

method

a function that belongs to the class. it gets a hidden first parameter, this, the object it was called on.

object

one instance of a class. a chunk of heap with a small header and the fields.

walk through it

two dogs, one birthday, and a second arrow to the same dog. press step and watch which box each line touches.

·

see? rex isn't a dog. it's an arrow to a dog. same = rex doesn't clone anything, it copies the arrow (the same rule as stack and heap: = copies what's in the slot).

methods live in the class

here's the thing: if every object carried its own copy of every method, a million dogs would mean a million copies of birthday(). instead, the method is stored once, and every call passes the object in as this:

rex.birthday()      is really      Dog.birthday(this = rex)

that's literally what the bytecode does: invokevirtual Dog.birthday, with the reference pushed first. inside the method, age with no prefix means this.age. you write this. yourself only when a local shadows a field, like the constructor's this.name = name (field on the left, parameter on the right).

Dog rex = new Dog("rex", 3);
Dog luna = new Dog("luna", 3);
rex.birthday();
IO.println(rex.age + " " + luna.age);

same fields, different objects

two objects built from the same blueprint with the same values are still two objects. == on references asks "are these the same arrow target?", not "do they look alike?".

Dog a = new Dog("rex", 3);
Dog b = new Dog("rex", 3);
IO.println(a == b);
IO.println(a.equals(b));

every object has an identity: it's this object, not merely one that looks the same. that's why printing a plain Dog gives you something like Dog@58fdd99: a class name and a hash of the identity, not the contents.

what one object costs

an object isn't just its fields. the JVM puts a small header in front: a mark word (hash, lock bits, GC age) and a pointer to the class, which is how a dog knows it's a Dog.

so an empty new Object() is 16 bytes, and a Dog with one reference and one int is 24. turn on compact headers and they drop to 8 and 16. that's the reason a million tiny objects can hurt more than you'd think, and why object layout gets its own chapter.