SE: Low Level Design

Low level Design (LLD)

It is the second phase design in the SDLC and it defines:

• the internal structure of the components APIs and Error handling for each module (internally)

It can be visualised using flowcharts and state-machine

It answers questions like:

• What classes exist?
• What methods do they expose?
• How do objects collaborate?
• How is state managed?

LLD operates at the code structure level:

• Classes and interfaces
• Methods and parameters
• Data structures
• Algorithms
• Error handling
• Threading / synchronization

Typical LLD Artifacts

• Class diagrams
• Sequence diagrams
• Interface definitions
• Pseudocode
• Database schemas

Design Principles at LLD

Object-Oriented Design is the foundation of LLD in most systems.

Core OOP Concepts

Encapsulation

Hide internal details, expose behavior.

class Motor {
private:
    int speed;
public:
    void setSpeed(int rpm);
};

Abstraction

Expose _what_ an object does, not _how_.

class Sensor {
public:
    virtual float read() = 0;
};

Inheritance

Reuse behavior via “is-a” relationships.

class TemperatureSensor : public Sensor {};

Polymorphism

Use different implementations through a common interface.

Sensor* s = new TemperatureSensor();

SOLID Principles (The Backbone of LLD)

SOLID principles guide how to design classes that scale.

• S: Single Responsibility Principle (SRP)
• O: Open/Closed Principle (OCP)
• L: Liskov Substitution Principle (LSP)
• I: Interface Segregation Principle (ISP)
• D: Dependency Inversion Principle (DIP)

Single Responsibility Principle (SRP)

A class should have **one reason to change**.

// A bad practice
class UserManager {
    void saveToDB();
    void sendEmail();
};

// A Good practice
class UserRepository {};
class EmailService {};

Open/Closed Principle (OCP)

Open for extension, closed for modification.

class PaymentMethod {
public:
    virtual void pay() = 0;
};

Add new payment types without modifying existing code.

Liskov Substitution Principle (LSP)

Derived classes must be usable wherever base classes are expected.

If Bird has fly(), a Penguin should not inherit from it.

Interface Segregation Principle (ISP)

Prefer many small interfaces over one large one.

class Printable {};
class Scannable {};

Not every device needs everything.

Dependency Inversion Principle (DIP)

Depend on abstractions, not concrete implementations.

class Controller {
    Device* device;
};

High-level modules should not depend on low-level modules, both should depend on abstractions.

Abstractions should not depend on details, Details should depend on abstractions.

Design Patterns

Design patterns are reusable solutions to recurring design problems.

They sit mostly in LLD, but influence HLD decisions too.

• Creational Patterns
• Structural Patterns
• Behavioral Patterns

Creational Patterns

Concerned with object creation.

• Factory
• Abstract Factory
• Singleton
• Builder

Example (Factory):

Device* DeviceFactory::create(Type t);

Structural Patterns

Concerned with object composition.

• Adapter
• Facade
• Decorator
• Proxy

Example (Adapter):

class OldAPIAdapter : public NewAPI {};

Behavioral Patterns

Concerned with object interaction.

• Observer
• Strategy
• Command
• State

Example (Observer):

sensor.attach(display);

Mapping Principles & Patterns to HLD and LLD