How to Model Classes From Requirements in LLD Interviews
Turn a machine-coding problem into classes: nouns become classes, verbs become methods, a Loan links Book and Member, and each rule lives with its data.
- Course: Low-Level Design study plan
- Module: From requirements to classes
- Kind: Lesson
- Reading time: 12 min
- Runtime: OpenJDK 18
How do you turn requirements into classes in a low-level design interview?
Fix the requirements first, then read them for nouns and verbs. Nouns that hold state become classes, verbs become methods on the class that owns the data they need, and a fact that belongs to two objects, such as a loan's due date, becomes a class of its own. Actors who use the system stay outside it.
Lesson
A machine-coding round opens with a paragraph of requirements and a blank editor. The first ten minutes decide the next fifty: the classes you pick are the ones you will be coding against. This lesson is the method, and the two programs after it are judged on what your classes do. The theory is in Introduction to Low-Level Design and UML class diagrams.
Read the requirements for nouns and verbs
A library lends books to members. A member may borrow up to two books for 14 days and return them; the desk can list the books that are overdue.
- Nouns that hold state become classes: Book (id, title), Member (name, loans), Library (everything on the shelf).
- Verbs become methods:
borrow,giveBack,overdue. - Facts become fields: the 14-day period and the limit of two are constants, not classes.
- Actors stay outside: the person at the desk calls
borrow; nothing about them is stored, so no Librarian class.
Give a shared fact its own class
The due day belongs to neither the book nor the member: it belongs to this book lent to this member. That is a Loan, an association class.
- Library is the class the desk calls: it finds books and members by key and offers the verbs of the brief — add, join, borrow, give back, list overdue.
- The library owns its books — composition, a filled diamond at the owner. A Book knows its id and title, and whether it is out right now.
- Members are owned the same way. A Member holds its own loans, which is what the two-book limit is counted from.
- The due day belongs to neither side, so the link gets a class: a Loan points at one book and one member. A book has at most one loan, a member at most two.
- Each rule sits with its data: overdueOn and daysLate read only the due day, so they live on Loan, and Library.overdue just asks each loan.
- Composition: the library owns its books and members.
- Association: a Loan points at one Book and one Member; a book has 0..1 loans, a member 0..2.
- Put each rule with its data:
overdueOn(day)reads only the due day, so it lives on Loan. The Library finds objects and calls them; it is not a god class holding every rule.
Run it
Every command is a method call, and every refusal is a rule some object owns.
ADD B1 Dune, ADD B2 Emma, JOIN ada, JOIN bo, then six commands- The state after the ADD and JOIN lines: two books on the shelf, two members holding nothing. Every later command is one method call on this model.
- ada borrows B1 on day 1: a new Loan links the book and the member, due on day 15, and both sides point at it.
- bo asks for B1, but the book already holds a loan. The Book refuses with an exception and main prints it after "error:"; nothing changes.
- bo borrows B2 on day 3: a new Loan links the book and the member, due on day 17, and both sides point at it.
- OVERDUE 16 asks every loan whether day 16 is past its due day: B1. Nothing is stored, so tomorrow's answer is never stale.
- B1 comes back on day 20. The loan ends, the member is down a book, and Loan.daysLate works out the 5 days late.
- OVERDUE 18 asks every loan whether day 18 is past its due day: B2. Nothing is stored, so tomorrow's answer is never stale.
- Refusals are exceptions with a message, caught once in
main, so no method returns magic strings. - Output order never depends on a
HashMap: books live in aTreeMapsorted by id.
The traps
- Storing derived state: an
overdueflag is wrong tomorrow; compute it from the due day. - Strings for objects:
Map<String, String> loansfrom book id to member name cannot hold a due day; the first new requirement breaks it. - One class doing everything: if every method of your design is on
Library, the entities are only records.
Common questions
Should an actor such as a librarian be a class?
Usually not. A librarian or a driver is someone who calls the system's methods; they become a class only when the system must remember something about them, such as an admin's permissions. Modelling every actor as a class adds objects that hold no state.
What is an association class in LLD?
It is a class that stands for a link between two objects and carries the facts of that link. A Loan joins one Book and one Member and holds the due date, which belongs to neither on its own; the book and the member each point at their loans.
Where should a method go in a class design?
On the class that owns the data the method needs. Whether a loan is overdue is decided from its due date, so overdueOn(day) belongs on Loan, not on Library. A method that reaches into another object's fields to decide something is a sign it sits on the wrong class.
What is a god class and how do I avoid it?
A god class is one class that holds every map and every rule, so every change touches it. Keep the coordinating class thin: it finds objects and calls them, while each entity checks its own rules, such as a book refusing a second loan.
Exercises
Library desk
Model a small library with Book, Member, Loan and a Library that finds them. The program reads commands until end of input, one per line, and prints one line for each.
| Command | Prints |
|---|---|
ADD <id> <title…> | added <id> (the title is the rest of the line) |
JOIN <name> | welcome <name> |
BORROW <name> <id> <day> | <name> borrowed <id> "<title>", due day <day + 14> |
RETURN <id> <day> | <id> returned on time, or <id> returned <n> days late (1 day late) |
OVERDUE <day> | overdue: <ids> — books on loan whose due day is before <day>, in id order as text (B1 B10 B2) — or overdue: none |
A member may hold at most two books. Refusals print error: <reason>, checked in this order:
ADDof an existing id:book <id> already exists;JOINof an existing name:member <name> already existsBORROW:no member <name>, thenno book <id>, then<id> is on loan, then<name> already has 2 booksRETURN:no book <id>, then<id> is not on loan- any other command:
unknown command <WORD>
A book returned on its due day is on time; it is overdue from the day after.
Roles and permissions
Model role-based access control: a Role holds permissions and may inherit other roles; a User holds roles; a user can do whatever any of their roles — or any role those inherit, at any depth — allows. Inheritance is live: a link added after an assignment counts at once.
| Command | Prints |
|---|---|
ROLE <role> [perm…] | role <role>: <perms sorted> or role <role>: none |
INHERIT <child> <parent> | <child> inherits <parent> |
USER <name> | user <name> |
ASSIGN <user> <role> | <user> is now <role> |
REVOKE <user> <role> | <user> is no longer <role> |
CAN <user> <perm> | yes or no |
PERMS <user> | <user>: <every permission, sorted> or <user>: none |
Refusals print error: <reason>:
role <r> already exists,user <u> already existsno role <r>(checking the child before the parent, the user before the role),no user <u>INHERIT:<child> already inherits <parent>for an existing direct link, thencyclewhen the parent is the child or already inherits from itASSIGN:<user> is already <role>;REVOKE:<user> is not <role>(also for a role that does not exist)- any other command:
unknown command <WORD>