LLD vs HLD - Learning Module

Loading content...

0/246

Low-Level Design: Classes, Objects, Methods, and Relationships

Where Architecture Meets Implementation

In the previous page, we explored the 30,000-foot view of High-Level Design—the world of services, databases, and data flows. Now we descend to ground level, where architectural blueprints become executable code. This is the realm of Low-Level Design (LLD).

If HLD answers "What components does this system have?", LLD answers "How is each component built internally?" It's the difference between knowing a building has floors, walls, and an elevator versus knowing the precise dimensions of each room, the material of each wall, and the mechanism of each door.

Low-Level Design is where software craftsmanship truly manifests. A well-designed class hierarchy, a thoughtfully abstracted interface, a method with exactly the right parameters—these are the marks of an engineer who understands not just what to build, but how to build it with elegance, maintainability, and extensibility.

What You Will Learn

By the end of this page, you will understand what Low-Level Design encompasses, the fundamental building blocks of LLD (classes, objects, methods, relationships), and how these elements combine to create well-structured, maintainable software components.

What Is Low-Level Design?

Low-Level Design (LLD) is the process of designing the internal structure of individual software components. While HLD defines what components exist and how they interact, LLD defines what's inside each component—the classes, interfaces, methods, and data structures that implement the component's functionality.

LLD is concerned with:

Classes and Objects — The fundamental building blocks of object-oriented systems
Interfaces and Contracts — The promises components make about their behavior
Methods and Functions — The executable units that perform work
Attributes and State — The data that objects hold and manage
Relationships — How objects know about and interact with each other
Design Patterns — Proven solutions to common design challenges
Data Structures — How data is organized within components
Algorithms — The step-by-step procedures that solve specific problems

The Scope of LLD

LLD operates at the component level. If HLD produced an architecture with a "User Service" box, LLD designs everything inside that box:

What classes does the User Service contain?
What are the responsibilities of each class?
How do classes collaborate to fulfill the service's purpose?
What interfaces abstract the implementation details?
What design patterns solve the specific challenges?
How is data validated, transformed, and persisted?
What methods does each class expose, and what are their contracts?

The Street-Level View

If HLD is viewing a city from an airplane, LLD is walking the streets. You see individual buildings, their entrances, their floor plans. You understand how people move through spaces, where they wait, how doors connect rooms. This ground-level perspective is essential for actually constructing something that works.

Classes: The Blueprint for Objects

Classes are the fundamental unit of organization in object-oriented design. A class defines a blueprint for creating objects—specifying what data they hold and what operations they can perform.

A class consists of:

Attributes (Fields) — The data that objects of this class contain. These define the state of an object.
Methods — The operations that objects can perform. These define the behavior of an object.
Constructors — Special methods that initialize new objects.
Access Modifiers — Keywords that control visibility (public, private, protected).

Class Structure Example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
// A well-designed class with clear responsibilities
class BankAccount {
    // Attributes (state)
    private readonly accountNumber: string;
    private balance: number;
    private readonly owner: string;
    private transactionHistory: Transaction[];
 
    // Constructor (initialization)
    constructor(accountNumber: string, owner: string, initialBalance: number = 0) {
        this.accountNumber = accountNumber;
        this.owner = owner;
        this.balance = initialBalance;
        this.transactionHistory = [];
    }
 
    // Methods (behavior)
    public deposit(amount: number): void {
        if (amount <= 0) {
            throw new Error("Deposit amount must be positive");
        }
        this.balance += amount;
        this.recordTransaction("DEPOSIT", amount);
    }
 
    public withdraw(amount: number): void {
        if (amount <= 0) {
            throw new Error("Withdrawal amount must be positive");
        }
        if (amount > this.balance) {
            throw new Error("Insufficient funds");
        }
        this.balance -= amount;
        this.recordTransaction("WITHDRAWAL", amount);
    }
 
    public getBalance(): number {
        return this.balance;
    }
 
    // Private helper method
    private recordTransaction(type: string, amount: number): void {
        this.transactionHistory.push({
            type,
            amount,
            timestamp: new Date(),
            balanceAfter: this.balance
        });
    }
}

What Makes a Good Class?

Not all classes are created equal. Well-designed classes share common characteristics:

Characteristics of Well-Designed Classes

•Single Responsibility — A class should have one reason to change. The BankAccount class is responsible for managing account state; it doesn't also handle user authentication or generate reports.
•High Cohesion — All attributes and methods should be related to the class's core purpose. Everything in BankAccount relates to account management.
•Encapsulation — Internal state is protected from external access. The balance is private; external code must use deposit() and withdraw().
•Clear Interface — Public methods form a clear, intuitive API. What the class does is obvious from its public surface.
•Appropriate Abstraction Level — The class operates at a consistent level of abstraction. It doesn't mix business logic with database queries.

Objects: The Living Instances

Objects are instances of classes—concrete manifestations of the abstract blueprint. While a class defines what a BankAccount is, an object is a specific bank account with a specific account number, owner, and balance.

Understanding objects requires grasping three fundamental concepts:

Identity — Each object is unique, even if two objects have identical state. Two BankAccount objects with the same balance are still different accounts.
State — The current values of an object's attributes. An account's state includes its balance, transaction history, and owner.
Behavior — What the object can do, defined by its methods. The account can deposit, withdraw, and report its balance.

Object Lifecycle

Objects have a lifecycle—they're created, used, and eventually destroyed:

Creation — Objects are instantiated via constructors. Memory is allocated, attributes are initialized.
Use — Objects receive method calls, their state changes, they collaborate with other objects.
Destruction — Objects are garbage collected (in managed languages) or explicitly deallocated. Resources are released.

Objects vs. Data Structures

Not everything that holds data is an object in the OOP sense. Data Transfer Objects (DTOs) and Value Objects are 'data structures'—they expose data and have minimal behavior. True objects hide their data and expose behavior. Understanding this distinction is crucial for good LLD.

Objects vs. Data Structures
Characteristic	Object (OOP)	Data Structure
Data Access	Encapsulated (private)	Exposed (public)
Behavior	Rich, domain-focused	Minimal or none
Purpose	Model domain concepts	Transfer or store data
Example	BankAccount, OrderProcessor	UserDTO, Point, Config
Changes	Add behavior easily, data changes hard	Add data easily, behavior changes hard

Methods: The Behavior Providers

Methods are where computation happens—the executable units that perform work. They're the verbs of your system, the actions that transform state, make decisions, and produce results.

A method has several components:

Name — What it does (verb phrase: calculateTotal, validateInput, sendNotification)
Parameters — What it needs to do its job (inputs)
Return Type — What it produces (output)
Body — The implementation (how it does its job)
Exceptions — What can go wrong (error conditions)

Method Categories

Methods serve different purposes in a class. Understanding these categories helps you design intentional APIs:

Method Categories and Naming Conventions
Category	Purpose	Naming Patterns	Examples
Queries	Return information without side effects	get, find, is, has, can*	getBalance(), findByEmail(), isActive()
Commands	Modify state or cause side effects	create, update, delete, set, add*	createOrder(), updateProfile(), deleteUser()
Calculations	Compute and return a value (pure)	calculate, compute, determine*	calculateTax(), computeHash()
Conversions	Transform between representations	to, as, from*	toString(), asDTO(), fromEntity()
Validation	Check conditions, return boolean or throw	validate, check, verify*	validateInput(), checkPermissions()
Factories	Create and return new objects	create, build, make, of	createUser(), List.of()

Principles of Good Method Design

•Do One Thing — A method should have a single, clear purpose. If you need 'and' to describe it ('validates and saves'), split it into two methods.
•Single Abstraction Level — Each method should operate at one level of abstraction. Don't mix high-level policy with low-level details.
•Command-Query Separation — Methods should either change state (commands) OR return data (queries), but not both. Exceptions exist but should be deliberate.
•Minimize Parameters — Fewer parameters are easier to understand. More than 3-4 suggests the method does too much or parameters should be grouped into an object.
•Avoid Side Effects — If a method is named 'validate', it shouldn't also modify the input. Side effects should be obvious from the name.

The Newspaper Metaphor

Good code reads like a newspaper: headlines (method names) at the top telling you what happens, details (implementation) as you read deeper. A developer should understand what a method does from its signature before reading the body.

Relationships: How Objects Connect

Objects don't exist in isolation—they relate to other objects. These relationships are fundamental to LLD because they determine how objects collaborate, how changes propagate, and how the system can evolve.

Understanding relationship types is essential for designing flexible, maintainable systems.

Object Relationship Types
Relationship	Description	UML Notation	Example
Association	Objects that know about each other	Solid line	Student ↔ Course (enrolled in)
Dependency	One object uses another temporarily	Dashed arrow	OrderProcessor → EmailService (uses)
Aggregation	'Has-a' with independent lifecycle	Empty diamond	Department ◇── Employee (contains)
Composition	'Has-a' with dependent lifecycle	Filled diamond	House ◆── Room (made of)
Inheritance	'Is-a' relationship	Empty triangle	Dog ▷── Animal (extends)
Realization	Implements an interface	Dashed triangle	PayPalProcessor ▷- - PaymentProcessor

Aggregation

•Whole contains parts
•Parts can exist independently
•Weak ownership
•Example: Library has Books
•Book exists without Library

Composition

•Whole contains parts
•Parts cannot exist independently
•Strong ownership
•Example: Order has OrderItems
•OrderItem meaningless without Order

Dependency Direction: The Key to Maintainability

The direction of dependencies is crucial. Well-designed systems have dependencies that flow in one direction—typically from high-level policy toward low-level details. This is the Dependency Inversion Principle in action.

Consider: Should OrderService depend on MySQLDatabase, or should both depend on an abstract Repository interface?

The second option is better because:

OrderService doesn't know or care about MySQL
You can swap databases without changing OrderService
Testing is easier with mock repositories
High-level business logic is protected from low-level infrastructure changes

Beware Circular Dependencies

If A depends on B, and B depends on A, you have a circular dependency. This makes code harder to understand, test, and modify. Break cycles by introducing abstractions (interfaces) or rethinking responsibilities.

Interfaces: Contracts Between Objects

Interfaces define contracts—promises about what an object can do without specifying how it does it. They are perhaps the most powerful abstraction mechanism in object-oriented design.

An interface declares:

Method signatures — What methods are available
Expected behavior — What calling those methods should do (documented)
Types — Input and output types for each method

An interface does NOT specify:

Implementation — How methods work internally
State — What data is stored
Performance — How fast operations are

Interface Example
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
// Interface defines WHAT, not HOW
interface PaymentProcessor {
    processPayment(amount: number, currency: string): Promise<PaymentResult>;
    refund(transactionId: string, amount?: number): Promise<RefundResult>;
    getTransactionStatus(transactionId: string): Promise<TransactionStatus>;
}
 
// Multiple implementations fulfill the same contract
class StripeProcessor implements PaymentProcessor {
    async processPayment(amount: number, currency: string): Promise<PaymentResult> {
        // Stripe-specific implementation
        const charge = await this.stripe.charges.create({ amount, currency });
        return { success: true, transactionId: charge.id };
    }
    // ... other methods
}
 
class PayPalProcessor implements PaymentProcessor {
    async processPayment(amount: number, currency: string): Promise<PaymentResult> {
        // PayPal-specific implementation
        const payment = await this.paypal.createPayment({ amount, currency });
        return { success: true, transactionId: payment.id };
    }
    // ... other methods
}
 
// Calling code works with ANY implementation
class CheckoutService {
    constructor(private paymentProcessor: PaymentProcessor) {}
    
    async checkout(cart: Cart): Promise<Order> {
        const result = await this.paymentProcessor.processPayment(
            cart.total, 
            cart.currency
        );
        // Works with Stripe, PayPal, or any future processor
    }
}

Power of Interfaces

•Multiple Implementations — Different classes can fulfill the same interface. Swap implementations without changing calling code.
•Testability — Tests can use mock or stub implementations that satisfy the interface.
•Decoupling — Code depends on abstractions, not concrete classes. Changes to implementations don't ripple to callers.
•Flexibility — Add new implementations (new payment provider) without modifying existing code.
•Documentation — Interfaces serve as contracts that document expected behavior.

Program to Interfaces, Not Implementations

This is one of the most important principles in OOP. When you depend on a concrete class, you're locked to that specific implementation. When you depend on an interface, you're free to use any implementation that fulfills the contract. This flexibility is the foundation of extensible design.

LLD Artifacts and Diagrams

Low-Level Design produces specific artifacts that guide implementation. These artifacts are more detailed than HLD diagrams and directly translate to code.

Key LLD Artifacts

•Class Diagrams — Show classes, their attributes, methods, and relationships. The canonical LLD diagram. Each class in the diagram becomes a class in code.
•Sequence Diagrams — Show how objects interact over time for specific scenarios. Essential for understanding complex flows and method call chains.
•State Diagrams — Show state transitions for stateful objects. Useful for entities with lifecycles (Order: Pending → Paid → Shipped → Delivered).
•Object Diagrams — Show specific object instances and their relationships at a point in time. Useful for complex scenarios.
•API Specifications — Detailed interface definitions (method signatures, parameter types, return types). The contract between classes.
•Database Schemas — Table definitions, columns, relationships, indexes. How persistent data is structured.

From Diagram to Code

Unlike HLD diagrams that remain somewhat abstract, LLD diagrams should be directly translatable to code:

Each class in a class diagram becomes a class/file in code
Each attribute in the diagram becomes a field in the class
Each method in the diagram becomes a method in the class
Each relationship becomes a field, parameter, or import

The diagram should be accurate enough that a developer could implement from it without ambiguity. This tight coupling between diagram and code is what makes LLD 'low-level.'

LLD: The Bridge Between HLD and Code

Low-Level Design serves as the critical bridge between High-Level Design (architecture) and actual code. It translates architectural concepts into implementation blueprints.

From HLD Concepts to LLD Implementation
HLD Concept	LLD Translation	Implementation
Service	Package/Module of classes	UserService/, OrderService/
API Endpoint	Controller class + methods	UserController.createUser()
Database Table	Entity class + Repository	User entity, UserRepository
Message Queue	Producer/Consumer classes	OrderEventPublisher, OrderEventHandler
Cache	Caching decorator or service	CachedUserRepository, CacheService
External System	Client/Adapter class	PaymentGatewayAdapter, EmailClient

The Translation Process

When you receive an HLD and need to produce LLD, you:

Identify entities — What domain objects does this service manage?
Define responsibilities — What does each class do? What does it own?
Establish relationships — How do classes interact? Who knows about whom?
Design interfaces — What contracts exist between components?
Apply patterns — What design patterns solve the challenges?
Plan for change — What's likely to change? How do we isolate it?

LLD Is Not Final

LLD is a plan, not a contract. As you implement, you'll discover nuances the design missed. Good LLD is detailed enough to guide implementation but flexible enough to accommodate discoveries. Document deviations and update the design.

Summary: The Building Blocks of LLD

We've explored the fundamental building blocks of Low-Level Design. Let's consolidate the key takeaways:

Key Takeaways

•LLD designs component internals — While HLD defines what components exist, LLD designs what's inside each component.
•Classes are blueprints — They define state (attributes) and behavior (methods) for objects.
•Objects are living instances — Each with identity, state, and behavior.
•Methods are behavior units — Well-designed methods do one thing, operate at one abstraction level, and have clear contracts.
•Relationships connect objects — Association, aggregation, composition, inheritance, dependency—each has specific meaning and implications.
•Interfaces define contracts — They separate what from how, enabling multiple implementations and testability.
•LLD artifacts guide implementation — Class diagrams, sequence diagrams, and specifications translate directly to code.
•LLD bridges HLD and code — It translates architectural concepts into implementable blueprints.

What's Next:

Now that we understand both HLD and LLD independently, we'll explore how LLD fits within the overall design process. The next page examines where LLD sits in the software development lifecycle, how it connects to requirements and architecture, and the iterative nature of design work.

Page Complete

You now understand Low-Level Design—the world of classes, objects, methods, and relationships where architectural blueprints become executable code. You know the fundamental building blocks and how they combine to create well-structured software. Next, we'll see how LLD fits into the broader design process.