Courses › Low-Level Design › Foundations

Class Modeling

From a vague prompt to entities, relationships, enums and a quick class diagram.

The first 10 minutes of an LLD round decide most of the outcome. If the entities and relationships are right, the code almost writes itself. If they're wrong, you spend the rest of the round patching. This lesson is a repeatable way to go from a vague prompt to a clean class model.

Step 1: Pin down the scope

Ask questions until you can list 3–6 core use cases. For a library system:

  • A member searches the catalog and borrows a copy.
  • A member returns a copy, and a late fee is charged if it's overdue.
  • A member reserves a book that's checked out, and is notified when it comes back.

Write these down. Everything you model should serve one of them. Also ask what's out of scope, such as payments, authentication or the UI.

Step 2: Nouns become candidate classes

Underline the nouns in your use cases: *member, catalog, book, copy, loan, fee, reservation, notification.* Then filter them:

  • Keep nouns that hold state and behavior: Member, BookCopy, Loan.
  • Demote nouns that are just a value to a field or an enum: a fee is an amount, and a status is an enum.
  • Merge synonyms: "user" and "member" are the same thing.

[!TIP] Book vs. copy Many prompts hide a type vs. instance split: a Book (title, ISBN) and the BookCopy items on the shelf, a Movie and a Show, a VehicleModel and a specific Car. Spotting it early impresses interviewers and avoids a painful refactor later.

Step 3: Verbs become methods, and pick an owner

Verbs from the use cases become methods: *borrow, return, reserve, notify.* For each one, ask which object holds the data the method needs. That object owns the method.

  • loan.is_overdue(today) lives on Loan, because Loan has the due date.
  • library.checkout(member, copy) coordinates several objects, so it belongs in a service class.

Avoid a "god class" that does everything, and avoid "anemic" classes that are only fields and getters.

Step 4: Relationships

State the multiplicity as well: one member has many loans, and each loan has exactly one copy.

Step 5: Draw it quickly

You don't need perfect UML. A box per class with its key fields and methods, plus labeled arrows, is enough:

[Library] -> [Catalog] -> [Book] -> [BookCopy]
[Library] -> [Member] -> [Loan] -> [BookCopy]
[Member] -> [Reservation] -> [Book]
Book       (isbn, title, authors)          1 ──< * BookCopy
BookCopy   (id, book, status: CopyStatus)
Member     (id, name, loans[], max_loans)
Loan       (copy, member, due_date, returned_at)  is_overdue(), fee()
LibraryService: checkout(member, copy), return_copy(copy), reserve(member, book)

Step 6: Model state explicitly

Anything with a lifecycle deserves an enum and allowed transitions, not a handful of booleans:

from enum import Enum

class CopyStatus(Enum):
    AVAILABLE = "available"
    ON_LOAN = "on_loan"
    RESERVED = "reserved"
    LOST = "lost"

is_borrowed, is_reserved and is_lost as three booleans allow combinations that make no sense. An enum makes them impossible. When the behavior changes a lot between states, use the State pattern. See Design a Vending Machine.

Inheritance or composition?

Use inheritance only for a real is-a relationship with shared behavior that subclasses don't override in odd ways. Prefer composition and interfaces for varying behavior:

  • Pricing rules, fee calculations, matching and spot assignment change independently of the entity, so use a Strategy.
  • Vehicle size is data, so use an enum field instead of a Truck subclass that only changes one number.

[!WARNING] Common modeling mistakes - Deep inheritance trees, like Vehicle → MotorVehicle → Car → ElectricCar, when an attribute would do. - Putting every method on one Manager class. - Using raw strings for statuses and types. - Modeling the UI or the database instead of the domain. - Forgetting the type vs. instance split.

Checking the model

Before you write code, walk each use case through the diagram out loud: "Checkout: the service checks member.can_borrow(), finds an available copy, creates a Loan and sets the copy to ON_LOAN." If a step has nowhere to live, the model is missing something.

[!TIP] Practice Library Management System · Parking Lot · Car Rental Booking · Amazon Locker · Q&A Site like Stack Overflow