LLD Design Process (From Requirements to Code)
Step 1: Understand Requirements
Before creating any class, understand what the system should do.
Ask:
- What features are required?
- What operations are supported?
- What are the future extensions?
Example: Document Editor
Requirements:
- Add Text
- Add Image
- Add New Line
- Add Tab Space
- Render Document
- Save Document
Never jump directly to classes.
First understand the problem.
Step 2: Extract Nouns → Classes
Nouns in requirements often become classes.
Example
Requirements:
- Add Text
- Add Image
- Save Document
Nouns:
- Document
- Text
- Image
- Storage
- Editor
Possible classes:
Document
TextElement
ImageElement
Storage
DocumentEditor
Another Example (Parking Lot)
Requirements:
- Park Vehicle
- Generate Ticket
- Multiple Floors
Nouns:
ParkingLot
Floor
Slot
Vehicle
Ticket
These become candidate classes.
Step 3: Find IS-A Relationships → Inheritance
Ask:
"Can I say child IS-A parent?"
Example
TextElement IS-A DocumentElement
ImageElement IS-A DocumentElement
NewLineElement IS-A DocumentElement
TabSpaceElement IS-A DocumentElement
Therefore:
DocumentElement
▲
|
----------------------------------
| | | |
TextElement ImageElement NewLineElement TabSpaceElement
Code
class DocumentElement {
public:
virtual string render() = 0;
};
class TextElement : public DocumentElement {};
class ImageElement : public DocumentElement {};
Rule
Use inheritance only when:
Child IS-A Parent
Examples:
Car IS-A Vehicle
Dog IS-A Animal
CreditCardPayment IS-A Payment
Step 4: Find HAS-A Relationships → Composition/Aggregation
Ask:
"What objects are contained inside another object?"
Example
A document contains elements.
vector<DocumentElement*> documentElements;
Meaning:
Document HAS-A collection of DocumentElements
UML:
Document 1 -------- * DocumentElement
Another Example
Parking Lot:
ParkingLot HAS-A Floors
Floor HAS-A Slots
Rule
Use composition/aggregation when:
Parent HAS-A Child
Examples:
Car HAS-A Engine
Document HAS-A Elements
ParkingLot HAS-A Floors
Step 5: Identify Actions → Methods
Ask:
"What actions can objects perform?"
Example
Document Editor:
Add Text
Add Image
Render
Save
Methods:
addText()
addImage()
render()
save()
Parking Lot
Actions:
parkVehicle()
unparkVehicle()
generateTicket()
Methods:
parkVehicle()
unparkVehicle()
Rule
Verbs become methods.
Nouns → Classes
Verbs → Methods
Step 6: Find Variations → Interfaces / Abstract Classes
Ask:
"What can change in the future?"
Example
Saving document:
File
Database
Cloud
These are different implementations.
Create abstraction:
Persistence
▲
|
--------------------
| |
FileStorage DBStorage
Code:
class Persistence {
public:
virtual void save(string data) = 0;
};
Why?
Tomorrow we can add:
class CloudStorage : public Persistence {};
without changing existing code.
Rule
When multiple implementations exist:
Create Interface / Abstract Class
Examples:
Payment
├─ UPI
├─ Card
└─ Cash
Storage
├─ File
├─ DB
└─ Cloud
Step 7: Draw UML
After identifying:
- Classes
- Methods
- Inheritance
- Composition
Draw UML.
Example
Document
|
| contains
v
DocumentElement
▲
|
-----------------------
| | |
Text Image NewLine
Persistence
▲
|
---------------
| |
FileStorage DBStorage
Step 8: Write Code
Convert UML to code.
Abstract Class
class DocumentElement {
public:
virtual string render() = 0;
};
Child Classes
class TextElement : public DocumentElement {};
class ImageElement : public DocumentElement {};
Composition
class Document {
private:
vector<DocumentElement*> elements;
};
Dependency Injection
class DocumentEditor {
private:
Persistence* storage;
};
Interview Thinking Framework
Whenever interviewer gives a problem:
Requirements
↓
Nouns
↓
Classes
↓
IS-A
↓
Inheritance
↓
HAS-A
↓
Composition
↓
Verbs
↓
Methods
↓
Variations
↓
Interfaces
↓
UML
↓
Code
Quick Cheat Sheet
Noun → Class
Vehicle
Ticket
Document
User
Payment
Verb → Method
park()
save()
render()
pay()
login()
IS-A → Inheritance
Car IS-A Vehicle
ImageElement IS-A DocumentElement
HAS-A → Composition
Car HAS-A Engine
Document HAS-A Elements
Future Variations → Interface
Payment
Storage
Notification
Logger
Final Flow:
Requirements
↓
Classes
↓
Inheritance
↓
Composition
↓
Methods
↓
Interfaces
↓
UML
↓
Code
