VOOZH about

URL: https://dev.to/roshan_singh_dd54d52bbaa7/lld-design-process-from-requirements-to-code-594m

⇱ LLD Design Process (From Requirements to Code) - DEV Community

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:

  1. Add Text
  2. Add Image
  3. Add New Line
  4. Add Tab Space
  5. Render Document
  6. 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