SOLID Principles

#Introduction

The SOLID Principles are five object-oriented design principles introduced by Robert C. Martin (Uncle Bob) to make software:

• Easier to understand
• Easier to maintain
• Easier to extend
• Easier to test
• Less coupled

Almost every Java/Spring Boot interview for 5+ years experience includes questions on SOLID because these principles are heavily used in enterprise applications.

#What is SOLID?

SOLID is an acronym:

Think of SOLID as a set of rules for writing clean, maintainable code.

#Why SOLID?

Imagine a single class containing:

• Database code
• Email code
• PDF generation
• Business logic
• Logging
• File handling

If one requirement changes, the entire class must be modified.

Problems:

• Difficult to test
• Difficult to debug
• Difficult to maintain
• High coupling
• Low readability

SOLID solves these problems.

#S — Single Responsibility Principle (SRP)

Definition

A class should have only one reason to change.

In simple words: a class should do only one job.

Bad Example

class EmployeeService {
    saveEmployee() {}
    generateSalary() {}
    sendEmail() {}
    exportPdf() {}
}

Responsibilities: save employee, salary calculation, email, PDF generation. Too many responsibilities — violation of SRP.

Good Design

Real-life example: Hospital

Each person has one responsibility.

Advantages

• Easy Maintenance
• Easy Testing
• Low Coupling
• Better Readability

#O — Open Closed Principle (OCP)

Definition

Software entities should be open for extension but closed for modification.

Meaning: when a new feature is added, do not modify existing code. Instead, extend it.

Bad Example

class PaymentService {
    public void pay(String type) {
        if (type.equals("CARD")) {
        }
        else if (type.equals("UPI")) {
        }
        else if (type.equals("NETBANKING")) {
        }
    }
}

Whenever a new payment type comes, this class must be modified. Violation.

Good Example

interface Payment {
    void pay();
}

class CardPayment implements Payment {
}

class UpiPayment implements Payment {
}

class WalletPayment implements Payment {
}

Now adding a new payment method only requires creating a new implementation. No existing code changes.

Real Project Example (Spring Boot)

Advantages

• Safer deployments
• Easier extension
• Fewer regression bugs

#L — Liskov Substitution Principle (LSP)

Definition

A child class should be replaceable by its parent without changing program behaviour.

Correct Example

Animal a = new Dog();
a.sound();

Works perfectly.

Wrong Example

class Bird {
    fly() {}
}

class Penguin extends Bird {
    fly() {
        throw new UnsupportedOperationException();
    }
}

Problem: penguins cannot fly. Bad inheritance — violation of LSP.

Better Design

Real-life example

Vehicle → Car, Bike, Truck. All support driving. If a child suddenly cannot perform the expected behaviour, the inheritance is incorrect.

#I — Interface Segregation Principle (ISP)

Definition

Clients should not be forced to depend on methods they do not use.

Bad Example

interface Worker {
    work();
    eat();
}

class Robot implements Worker {
    work() {}
    eat() {
        // meaningless
    }
}

A robot doesn't eat. Violation.

Good Design

interface Workable {
    work();
}

interface Eatable {
    eat();
}

Perfect.

Advantages

• Smaller interfaces
• Cleaner design
• Better flexibility

Real Project Example

Instead of one UserOperations interface having login(), logout(), payment(), refund(), downloadInvoice() and cancelTicket(), split it into:

#D — Dependency Inversion Principle (DIP)

This is probably the most important SOLID principle for Spring developers.

Definition

High-level modules should not depend upon low-level modules. Both should depend upon abstractions.

Bad Example

class Car {
    Engine engine = new Engine();
}

Car depends directly on Engine. If the engine changes, Car changes. Tightly coupled.

Good Example

interface Engine {
    start();
}

class PetrolEngine implements Engine {
}

class DieselEngine implements Engine {
}

class ElectricEngine implements Engine {
}

class Car {
    Engine engine;
}

Now Car depends on an abstraction.

Spring Boot Example

@Service
class UserService {

    @Autowired
    UserRepository repository;
}

UserService depends on UserRepository, which is an abstraction. Spring injects the implementation. This is Dependency Inversion.

Why Does Dependency Injection Exist?

Dependency Injection is a technique used to implement Dependency Inversion.

• Dependency Inversion is a design principle.
• Dependency Injection is its implementation.

Advantages

• Loose Coupling
• Easy Unit Testing
• Easy Mocking
• Replace implementations easily

#Complete SOLID Diagram

#SOLID in Spring Boot