Java Classes and Objects

A class is a blueprint/template that defines the state (fields) and behavior (methods) shared by objects of that type. It's also a namespace for constructors, nested types, and static members. You create objects (instances) from it with new.

public class Car {
    private String model;              // state (field)
    Car(String model) { this.model = model; }   // constructor
    void drive() { System.out.println(model + " driving"); }  // behavior
}

Key elements interviewers expect: fields, methods, constructors (initialize new objects), access modifiers (public/private/…), and optionally static members (class-level) and nested classes. A class defines a type and supports encapsulation, inheritance, and polymorphism.

A current note that signals up-to-date knowledge: Java now has specialized class forms — record (Java 16+) for concise, immutable data carriers (auto-generates constructor, accessors, equals/hashCode/toString), enum for fixed instances, and sealed classes (Java 17+) to restrict which classes may extend them. So while the "blueprint for objects" definition is correct, mentioning records/sealed classes shows you know how modern Java models data and hierarchies.

An object is a concrete instance of a class — a runtime entity that has its own state (the values of its fields) and behavior (the methods it can run). Where the class is the blueprint, the object is the actual thing built from it, living on the heap and referenced by a variable.

Car c1 = new Car("Tesla");   // c1 references a Car object
Car c2 = new Car("BMW");     // a separate object with its own state

Points interviewers like: objects are created with new (which allocates heap memory and runs a constructor), each has its own copy of instance fields, and variables hold references to objects (not the objects themselves) — which is why == compares references and assignment copies the reference, not the object. Objects are reclaimed automatically by the garbage collector when no longer reachable (no manual delete).

A current note: not everything is created with new anymore — records and factory methods (List.of(...), Optional.of(...)) are common ways to obtain objects, and value-like data is often modeled as immutable objects/records. The core idea stands: an object is a class instance with identity, state, and behavior.

A class is the definition/blueprint — a compile-time construct describing what fields and methods instances will have. An object is a runtime instance of that class, with its own state, created with new.

class Car { String model; }        // the class (one definition)
Car a = new Car();                 // object #1 (its own state)
Car b = new Car();                 // object #2 (separate state)

The distinctions interviewers want:

• One class, many objects — the class is declared once; you can create unlimited instances, each with independent field values.
• Memory — a class definition is metadata (loaded once into the method area/metaspace); each object occupies its own space on the heap.
• Lifetime — a class is loaded by a class loader and stays; objects are created on demand and garbage-collected when unreachable.
• Identity — distinct objects have distinct identities even with equal field values (== is false unless they're the same instance).

A neat analogy: the class is the recipe, objects are the cakes baked from it. Modern note: some types blur this — a record is still a class producing objects, and enum instances are a fixed set of objects created once — but the class-vs-object distinction (definition vs instance) holds throughout.

Inheritance lets a class acquire the fields and methods of another class, modeling an "is-a" relationship and enabling code reuse and polymorphism. The class that inherits is the subclass (extends keyword); the one inherited from is the superclass.

class Animal { void eat() { ... } }
class Dog extends Animal {           // Dog is-an Animal
    void bark() { ... }
}
new Dog().eat();   // inherited from Animal

Points interviewers expect: a subclass can add members and override inherited methods (runtime polymorphism); super accesses the parent's members/constructor; every class implicitly extends Object; and Java allows single class inheritance but multiple interface inheritance (a class can implement many interfaces). Constructors are not inherited, and a subclass constructor implicitly calls super() first.

The crucial modern caveat: prefer composition over inheritance. Deep inheritance hierarchies are brittle ("fragile base class"), so favor has-a composition and interfaces unless there's a genuine is-a relationship. Java reinforces this with sealed classes (Java 17+), which let a superclass permit only specific subclasses — giving controlled, exhaustive hierarchies that pair well with pattern matching. So: inheritance is fundamental, but use it deliberately and lean on composition/interfaces by default.

Polymorphism ("many forms") lets the same interface/reference operate on different underlying types, with the right behavior chosen for the actual object. Java has two kinds:

• Compile-time (static) polymorphism — method overloading; the compiler picks the method from the argument types.
• Runtime (dynamic) polymorphism — method overriding; a superclass/interface reference points to a subclass object, and the JVM dispatches to the object's actual method at runtime.

List list = new ArrayList<>();   // program to the interface
Animal a = new Dog();
a.sound();   // calls Dog's overridden sound() — decided at runtime

Why it matters: it enables writing code against a general type (an interface or base class) while behavior varies by concrete type — the foundation of extensible, loosely-coupled design (e.g. List backed by ArrayList or LinkedList; a Comparator parameter accepting any comparison).

A current note: modern Java complements classic subtype polymorphism with pattern matching for switch over sealed hierarchies — instead of overriding a method per subtype, you can branch on type exhaustively and safely:

String describe(Shape s) {
    return switch (s) {                 // sealed Shape: Circle, Square
        case Circle c -> "circle";
        case Square sq -> "square";
    };
}

So polymorphism today spans overriding/overloading and pattern matching — knowing both is what signals current Java fluency.

One of the most common Java interview questions. The rule: if two objects are equal by equals(), they must have the same hashCode() (the reverse isn't required — unequal objects may share a hash code, a collision). Consequences of the full contract: hashCode() must be consistent across calls, and equals() must be reflexive, symmetric, transitive, and consistent.

Why it matters: hash-based collections (HashMap, HashSet) rely on it. They locate an entry by hashCode() (which bucket) and then confirm with equals(). If you override equals() but not hashCode(), equal objects can land in different buckets, so map.get(key)/set.contains(x) fail to find entries — a classic bug.

record Point(int x, int y) {}   // record auto-generates equals/hashCode correctly
// or override BOTH together:
@Override public boolean equals(Object o) { ... }
@Override public int hashCode() { return Objects.hash(x, y); }

Best practices: always override both together, use Objects.equals/Objects.hash, base them on the same fields (ideally immutable ones), and prefer a record for value types since it implements both correctly for free. Interviewers love asking "what happens if you override equals but not hashCode?" — the answer is broken lookups in hash collections.

A record (finalized in Java 16) is a concise way to declare an immutable data carrier. From a one-line declaration, the compiler generates the private final fields, canonical constructor, accessors, and equals()/hashCode()/toString() — eliminating boilerplate:

public record Point(int x, int y) {}
// auto: constructor, x(), y(), equals, hashCode, toString — all correct

Use records for value/DTO-like types: API request/response objects, map keys, tuples, immutable domain values. You can add a compact constructor for validation, implement interfaces, and add static factory methods/instance methods:

public record Range(int lo, int hi) {
    public Range {                              // compact constructor — validation
        if (lo > hi) throw new IllegalArgumentException();
    }
}

Constraints to mention: records are implicitly final, can't extend a class (they extend Record), and their fields are final (shallow immutability — a mutable field's contents can still change, so prefer immutable components). They pair powerfully with sealed interfaces + pattern matching (record patterns, Java 21) for clean, exhaustive data modeling. Records are a top "do you know modern Java?" question.