How do you identify classes from a problem statement in LLD?

Direct Answer

Identify nouns in the problem statement — these become candidate classes. Filter to entities that have both data (attributes) and behavior (methods). Actors like managers and controllers often become classes or interfaces. Validate each class by ensuring it has clear responsibilities.

Deep Dive & Architecture

Candidate entities from nouns and rules

Underline nouns, verbs, and rules in the prompt. Nouns suggest entities or values, verbs suggest behaviour, and rules suggest invariants. In “a member borrows a book copy and receives a fine when it is late,” Member, BookCopy, and Loan have identity or state. “Late” is a condition, not a class by itself.

Entity responsibility test

Ask whether the candidate owns state, enforces a rule, or coordinates a use case. Loan deserves a class because it records issue and due dates. FinePolicy may be an interface when different member types use different rules. A vague LibraryManager is not a useful answer until its exact job is named.

Walk one use case through the objects

For borrowing, Catalog finds an available copy, BorrowingService checks the member and creates a Loan, and BookCopy changes from available to loaned. Walking the flow exposes missing objects and misplaced behaviour. The first class list is a draft; refine it after responsibilities and relationships are clear.

Code Example

// Prompt: "A member borrows a book; if returned late, a fine applies."
// Nouns -> classes; verbs -> methods; adjectives -> fields.
class Member {                 // noun -> class
    private String name;       // attribute
    void borrow(Book book) { } // verb -> method on the actor
}
class Book {                   // noun -> class
    private String title;      // attribute
    private boolean available; // adjective -> field
}
class Fine {                   // noun -> class (has data + behaviour)
    private BigDecimal amount;
    BigDecimal calculate(long overdueDays) { return amount.multiply(BigDecimal.valueOf(overdueDays)); }
}

Keep only nouns that have state and behaviour; "late" is a condition, not a class.

Common Mistakes & Pitfalls

• Turning every noun into a class — "late", "name", "price" are attributes/values, not classes.
• Missing actor classes — "librarian" or "manager" often need a class or service.
• Classes with data but no behaviour — that's a struct; ask what it does.
• Ignoring relationships — finding classes is step one; how they connect is step two.