What if you could turn confusing requirements into a clear, simple blueprint for your software?
Why Identifying classes from requirements in LLD? - Purpose & Use Cases
Imagine you have a big list of features and rules for a new app written in plain text. You try to build the app by guessing what parts you need, writing code without clear structure.
You keep adding bits here and there, but soon the code is messy and confusing.
Without clear classes, your code becomes a tangled mess. It's hard to find where things belong, and fixing one part breaks another.
Adding new features takes forever because you don't know where to put them. Bugs hide in the chaos, and teamwork becomes a nightmare.
Identifying classes from requirements helps you spot the main objects and their roles early on.
This gives your design a clear shape, like sorting tools into labeled boxes. Each class has a purpose, making the code easier to build, understand, and change.
if user_is_logged_in: show_dashboard() else: show_login() # everything mixed in one place
class User: def login(self): pass class Dashboard: def display(self): pass # clear roles separated
It enables building software that is organized, easy to maintain, and ready to grow without chaos.
Think of designing a library system: by identifying classes like Book, Member, and Loan early, you create a clear map that guides the whole project smoothly.
Manual coding without classes leads to messy, fragile code.
Identifying classes organizes requirements into clear, manageable parts.
Clear classes make software easier to build, fix, and expand.
Practice
Solution
Step 1: Identify nouns in the requirement
Classes usually come from nouns. Here, 'Book' is a noun representing an object.Step 2: Differentiate between nouns and verbs
'Borrow', 'Return', and 'Search' are actions (verbs), so they are methods, not classes.Final Answer:
Book -> Option CQuick Check:
Class = Noun = Book [OK]
- Choosing verbs as classes
- Confusing actions with objects
- Ignoring nouns in requirements
Solution
Step 1: Understand class syntax in LLD context
Classes are defined with the keyword 'class' followed by the class name.Step 2: Check options for class declaration
class Driver {} uses 'class Driver {}' which is correct syntax for a class.Final Answer:
class Driver {} -> Option AQuick Check:
Class syntax uses 'class' keyword [OK]
- Using function instead of class
- Assigning class name to variable
- Confusing variables with classes
Solution
Step 1: Extract nouns from the requirement
The nouns are Guests, Rooms, and Bookings, which represent objects.Step 2: Match nouns to class names
Classes should be singular nouns representing entities: Guest, Room, Booking.Final Answer:
[Guest, Room, Booking] -> Option BQuick Check:
Classes = Nouns = Guest, Room, Booking [OK]
- Using verbs as classes
- Using plural or combined names incorrectly
- Adding unrelated terms
Solution
Step 1: Identify nouns and verbs
'User' is a noun (class), 'login' and 'logout' are actions (methods).Step 2: Check option correctness
Class: Login; Methods: user(), logout() incorrectly uses 'Login' as a class and 'user()' as a method, which reverses noun and verb roles.Final Answer:
Class: Login; Methods: user(), logout() -> Option DQuick Check:
Class = noun, Method = verb [OK]
- Using verbs as classes
- Naming methods as nouns
- Mixing class and method roles
Solution
Step 1: Identify all nouns in the requirement
Nouns are Customers, Orders, Restaurants, Meals, DeliveryAgents.Step 2: Use nouns as class names and verbs as methods
Classes should be Customer, Order, Restaurant, Meal, DeliveryAgent. Actions like 'place' and 'deliver' become methods.Final Answer:
[Customer, Order, Restaurant, Meal, DeliveryAgent] -> Option AQuick Check:
Classes = Nouns only, verbs become methods [OK]
- Using verbs as classes
- Combining nouns incorrectly
- Omitting important entities
Ready to prove it?
Pass the test and this pattern moves unknown
