Classes and Objects

Introduction

Object-oriented design organizes software around classes (templates) and objects (runtime instances). In LLD interviews, every noun in the problem statement is a candidate class; every verb suggests a method or collaboration.

Java makes this concrete: a Book class defines state and behavior; each copy on the library shelf is an object with its own ISBN and availability flag. Getting class boundaries right early saves painful refactors later.

This lesson establishes naming, fields, methods, and object lifecycles — the vocabulary for every subsequent LLD problem.

Understanding the topic

Key concepts

• Class: blueprint with fields (state) and methods (behavior).
• Object: instance with its own field values created via constructors or factories.
• Identity vs equality: two Book objects may share ISBN (value) but differ by copy id (identity).
• Static members belong to the class; instance members belong to each object.
• Constructors enforce invariants (non-null title, positive page count).
• Package-private + public API surface keeps models maintainable.

flowchart TB
  Encapsulation --> Abstraction
  Abstraction --> Inheritance
  Inheritance --> Polymorphism

Step-by-step explanation

1. Identify entities from requirements (Member, Book, Loan).
2. Decide what each class knows (fields) vs what it does (methods).
3. Use constructors or factory methods to create valid objects only.
4. Collaborate via references — objects call methods on other objects.
5. Garbage-collect or pool objects when lifecycle ends (return book, close ticket).
6. Document which objects are long-lived singletons vs per-request instances.

Informative example

Library domain — each object owns clear state and exposes domain operations:

public final class Book {
    private final String isbn;
    private final String title;
    private boolean available;

    public Book(String isbn, String title) {
        this.isbn = Objects.requireNonNull(isbn);
        this.title = Objects.requireNonNull(title);
        this.available = true;
    }

    public String isbn() { return isbn; }
    public String title() { return title; }
    public boolean isAvailable() { return available; }

    void markLoaned() {
        if (!available) throw new IllegalStateException("already loaned");
        available = false;
    }

    void markReturned() { available = true; }
}

public final class Member {
    private final String id;
    private final String name;

    public Member(String id, String name) {
        this.id = id;
        this.name = name;
    }

    public String id() { return id; }
    public String name() { return name; }
}

Keep fields private; expose read-only accessors. Domain mutations (markLoaned) stay package-private so only LoanService orchestrates transitions.

Real-world use

Real-world applications

• Modeling domain entities in any LLD interview problem.
• Translating ER diagrams into Java classes (with behavior, not anemic data bags).
• Unit testing object collaborations with mocks.

Best practices

• One primary responsibility per class — resist mega-entities.
• Prefer immutable fields where state does not change (ISBN, member id).
• Use meaningful names aligned with the problem domain.
• Validate constructor arguments — fail fast on invalid objects.
• Avoid public mutable fields.
• Distinguish entity (has identity) from value object (defined by attributes).

Common mistakes

• Anemic model: only getters/setters with logic scattered in helpers.
• Confusing class diagrams with database tables only.
• Creating new objects when updating existing ones (losing identity).
• Static abuse — everything in utility classes instead of objects.

Advanced interview questions

Summary

Classes define structure; objects are runtime instances with state. Map nouns to classes and verbs to methods or services. Constructors and factories enforce valid object creation. Private fields + domain methods beat public data bags. Records suit immutable values; classes suit rich behavior.