Classes and Objects in Java

Every Java application is built on classes and objects. They are the foundation of object-oriented programming — the blueprint versus the building.

Introduction

A class defines the blueprint for creating objects — it specifies the fields (state) that each instance holds and the methods (behavior) that operate on that state. When you write new Robot("Wall-E"), the Robot class constructor is invoked and memory is allocated for a new instance with its own copy of all instance fields. Multiple objects created from the same class share the same method code but maintain independent state values.

Objects live on the heap; references to them live on the stack. A reference variable holds the memory address of an object, not the object itself. This distinction matters because multiple references can point to the same object, and if one reference modifies the object’s state, all other references see the change. Understanding this shared-mutability model is critical for avoiding subtle bugs in code that appears correct in isolation.

This guide covers the anatomy of a class, how objects are instantiated, how references and objects relate to each other in memory, and the design principles that separate good class design from problematic patterns. Understanding classes and objects is the prerequisite for all other object-oriented concepts in Java — inheritance, polymorphism, encapsulation, and abstraction all build on this foundation.

When to Use

Use a class when you need to:

• Model real-world entities with state (fields) and behavior (methods)
• Encapsulate related data and logic that belong together
• Create multiple instances sharing the same structure but different state
• Organize code into logical units that can be tested and maintained independently

// Defining a class — the blueprint
public class Robot {
    // Fields — state
    private String name;
    private int batteryLevel;

    // Constructor — initializes new instances
    public Robot(String name) {
        this.name = name;
        this.batteryLevel = 100;
    }

    // Method — behavior
    public void charge() {
        this.batteryLevel = Math.min(100, batteryLevel + 20);
    }
}

// Instantiating objects — the buildings
Robot r2d2 = new Robot("R2-D2");
Robot c3po = new Robot("C-3PO");

// Anonymous class for one-off behavior
Runnable task = new Runnable() {
    @Override
    public void run() {
        System.out.println("Executing task");
    }
};

When Not to Use

Avoid classes for:

• Pure utility functions — use static methods in a utility class instead
• Single-value data containers — consider a record in Java 16+
• Data that only wraps primitives — use primitives directly or record
• One-off scripts — top-level code in a main method may suffice for simple programs

// Don't do this — unnecessary class for a simple operation
class StringUtils {
    public static String capitalize(String s) {
        return s.isEmpty() ? s : Character.toUpperCase(s.charAt(0)) + s.substring(1);
    }
}
// Better: use a simple static utility class is fine, but for simple capitalize, consider if it's truly needed

Class Anatomy — Mermaid Diagram

classDiagram
    class Robot {
        -String name
        -int batteryLevel
        +Robot(String name)
        +charge() void
        +getName() String
    }
    Robot : +new Robot("R2-D2")

Failure Scenarios

1. Uninitialized Reference

Robot robot;           // Declared but not assigned
robot.charge();       // NullPointerException — robot is null

// Fix: always initialize before use
Robot robot = new Robot("Wall-E");

2. Mutable Shared State via References

List<String> list1 = new ArrayList<>();
List<String> list2 = list1;    // Both reference the SAME list
list2.add("item");             // Modifies list1 too

// Fix: create independent copies
List<String> list2 = new ArrayList<>(list1);

3. Forgetting the new Keyword

String s = String.valueOf(42);  // Factory method — correct
Robot r = Robot("Test");        // Compile error — forgot new
Robot r = new Robot("Test");     // Correct

Trade-off Table

Approach	Use Case	Drawback
Concrete class	Full control over behavior and state	More boilerplate
Abstract class	Shared base with partial implementation	Single inheritance limit
Interface	Multiple contracts without implementation	No state
Record (Java 16+)	Immutable data carrier	Cannot hold mutable state
Enum	Fixed set of constants	Not extendable at runtime

Code Snippets

Static Factory Method Pattern

public class Robot {
    private final String name;

    private Robot(String name) {  // Private constructor
        this.name = name;
    }

    // Static factory method instead of public constructor
    public static Robot createVacuumBot(String name) {
        return new Robot(name);
    }

    public static Robot createSecurityBot(String name) {
        Robot bot = new Robot(name);
        // Security bot specific setup
        return bot;
    }
}

// Usage
Robot vac = Robot.createVacuumBot("Roomba");
Robot sec = Robot.createSecurityBot("Guard");

Nested Class

public class Outer {
    private String outerField = "outer";

    public class Inner {
        private String innerField = "inner";
        public void accessOuter() {
            System.out.println(outerField);  // Can access outer class field
        }
    }
}

// Instantiate inner class via outer instance
Outer outer = new Outer();
Outer.Inner inner = outer.new Inner();

Observability Checklist

• Fields are private with controlled access via getters/setters
• Constructor validates required parameters
• Immutable classes use final fields and no setters
• Static fields documented with their purpose
• Thread-safe design for shared instances

Security Notes

• Encapsulate fields — never expose internal state directly
• Defensive copies — when returning collections from getters, return copies not references
• Immutable objects — prefer immutability to avoid race conditions
• Input validation — validate all constructor and setter parameters

public class User {
    private final List<String> roles;  // Mutable field

    public List<String> getRoles() {
        return List.copyOf(roles);  // Return defensive copy — prevents external modification
    }
}

Pitfalls

1. Creating too many classes — each class should earn its place
2. God objects — classes that do too much; split into focused units
3. Tight coupling — classes that depend heavily on each other’s internals
4. Mutable fields that shouldn’t be — default to final where possible
5. Reassigning parameters — don’t modify parameter values inside methods

// Bad: modifying parameter
public void process(User user) {
    user = new User();  // This only changes local copy, not the caller's reference
}

// Good: operate on the object, don't reassign
public void process(User user) {
    user.updateStatus("active");  // Call methods on the object
}

Quick Recap

• Class = blueprint defining state (fields) and behavior (methods)
• Object = instance created from a class via new
• Reference = variable holding object’s memory address
• Encapsulation = keep fields private, expose via methods
• Immutability = use final fields and no setters

Interview Questions

Further Reading

• Constructors — initializing objects with constructors and constructor overloading
• Fields and Instance Variables — managing object state
• Encapsulation — hiding internal state with access modifiers
• Inheritance — subclassing and the extends keyword
• Polymorphism — runtime method dispatch through inheritance

Summary

Classes and objects form the bedrock of Java’s object-oriented model. A class defines the blueprint — the fields that hold state and the methods that provide behavior — while objects are live instances created via the new keyword, each with their own memory for instance fields.

Understanding the distinction between references and objects is critical: a reference is a pointer to an object’s location in heap memory, and multiple references can point to the same object. This is why defensive copying matters for mutable types.

The class anatomy diagram shows how fields (state) and methods (behavior) work together. When designing classes, favor encapsulation by keeping fields private and exposing controlled access points. This prevents external code from putting objects into invalid states.

For one-off behavior, anonymous classes and lambda expressions (for functional interfaces) let you create objects without formal class definitions. Static factory methods offer an alternative to constructors for cases where you need to return cached instances, subclasses, or want more expressive creation syntax.

Classes integrate closely with other OOP concepts: constructors (covered in Java Constructors) initialize new instances, fields (detailed in Fields and Instance Variables) hold the per-object state, and methods define behavior that subclasses can override to achieve polymorphism (explored in Polymorphism in Java).