Classes and Objects in Java: The Building Blocks

Everything in Java lives inside classes, and everything you manipulate at runtime is an object. Getting the relationship between the two exactly right is the foundation the rest of object-oriented programming is built on — mix them up and inheritance, polymorphism, and encapsulation never quite make sense.

This tutorial makes the class-versus-object distinction concrete, then goes into the part beginners underestimate: references. If you want the wider map of OOP first, the four OOP concepts overview shows where classes and objects sit among the pillars.

Class is the blueprint, object is the thing

A class is a design — it says what a type will have and can do, but it is not a real thing yet. An object is an actual instance built from that design, occupying memory and holding real values.

The standard analogy holds up: a class is the architectural drawing of a house; objects are the actual houses built from it. One drawing, many houses, each with its own address and paint color.

A class bundles two things:

• Fields (also called instance variables) — the state, the data each object carries.
• Methods — the behavior, what each object can do with its state.

class Car {
    // fields: state
    String model;
    int speed;

    // method: behavior
    void accelerate(int delta) {
        speed += delta;
        System.out.println(model + " now at " + speed);
    }
}

Car is just a definition here. No car exists yet — we've only described what a car is.

Creating objects with new

The new keyword turns the blueprint into a real object. It allocates memory, runs the constructor, and hands you a reference.

public class Main {
    public static void main(String[] args) {
        Car c1 = new Car();     // one object
        c1.model = "Swift";
        c1.speed = 40;

        Car c2 = new Car();     // a completely separate object
        c2.model = "i20";
        c2.speed = 60;

        c1.accelerate(20);      // Swift now at 60
        c2.accelerate(10);      // i20 now at 70
    }
}

What to notice: c1 and c2 are built from the same class but are entirely independent. Changing c1.speed never touches c2.speed because each object has its own copy of the instance fields. That independence is the whole point of instance variables — contrast it with the single shared copy a static variable gives you.

The part that trips beginners: references

This is where careful understanding pays off. In Java, a variable like Car c1 does not hold the car object. It holds a reference — an arrow pointing to where the object lives in heap memory. The object and the variable are two different things.

Why does that matter? Because two variables can point at the same object.

public class Main {
    public static void main(String[] args) {
        Car a = new Car();
        a.model = "Nexon";

        Car b = a;          // b points to the SAME object, no new object
        b.model = "Harrier";

        System.out.println(a.model); // Harrier — surprised?
    }
}

There is only one object here. b = a copied the arrow, not the car. So changing b.model changes the single shared object, and reading a.model shows the change. If you wanted an independent duplicate, you would need a copy constructor, not a plain assignment.

Common mistake: Thinking Car b = a; creates a second car. It copies the reference, so both variables point to one object. This is the root cause of countless "why did my other variable change?" bugs, and it is a favorite interview question because it separates people who truly understand references from those who don't.

null: a reference pointing at nothing

A reference variable can point at no object at all. That value is null.

Car ghost = null;        // valid reference, no object
// ghost.accelerate(10); // NullPointerException at runtime

Calling a method on a null reference throws the famous NullPointerException, because there is no object to run the method on. Every Java developer meets this error early; the fix is always "make sure the reference actually points to an object before you use it."

Fields, methods, and the this reference

Inside a method, how does the object know which object's fields to use? Through an implicit reference called this, which means "the object this method was called on."

class Student {
    String name;

    void setName(String name) {
        this.name = name;   // this.name = field, name = parameter
    }
}

Here this.name is the object's field and name is the parameter. Without this, the assignment would just set the parameter to itself and the field would stay unchanged — a subtle bug. You'll rely on this constantly once field and parameter names collide.

Pro tip: Give constructor and setter parameters the same name as the fields and use this.field = param. It reads naturally and is the standard Java convention, so recruiters and reviewers expect to see it.

Objects combine state and behavior

The reason objects are powerful is that they keep data and the operations on that data together. A BankAccount object holds its own balance and knows how to deposit and withdraw.

class BankAccount {
    private double balance;

    BankAccount(double opening) {
        this.balance = opening;
    }

    void deposit(double amount) {
        if (amount > 0) balance += amount;
    }

    double getBalance() {
        return balance;
    }
}

public class Main {
    public static void main(String[] args) {
        BankAccount acc = new BankAccount(1000);
        acc.deposit(500);
        System.out.println(acc.getBalance()); // 1500.0
    }
}

Notice balance is private — outside code can't set it to a negative number directly; it must go through deposit, which validates the amount. That pairing of private data with public methods is encapsulation, and it starts right here with how you design a class.

Instance vs local variables

Two kinds of variables live in a class, and confusing them causes real bugs:

The "must assign before use" rule for locals is why the compiler rejects code that reads a local variable you never initialized, while an instance field can be read immediately because it defaults to 0, false, or null.

Why this is the foundation

Every other OOP idea builds on classes and objects. Inheritance creates new classes from existing ones. Polymorphism relies on a parent reference pointing to a child object — which only makes sense once you understand references. Even collections like ArrayList store references to objects, not the objects themselves.

Get comfortable creating classes, instantiating objects, and reasoning about references, and the rest of Java stops feeling like disconnected rules.

Where to go next

Now that objects exist, learn how they get initialized properly with constructors in Java, then protect their state with encapsulation. When you're ready to build real applications where dozens of objects collaborate, the Java Full Stack course takes you from single classes to full systems, and the Java learning hub lays out the complete path.