Single Responsibility Principle (SRP)

• L – Liskov Substitution Principle (LSP)
• I – Interface Segregation Principle (ISP)
• D – Dependency Inversion Principle (DIP)

Real-World Problem

Imagine you're developing an E-Commerce Management System. Initially, the Order class is responsible only for calculating the total order amount. As the application grows, new business requirements arrive. The client requests invoice generation, email notifications, database storage, payment logging, and report generation. Since the Order class already exists, developers continue adding these features to the same class.

At first, this approach seems convenient because everything related to an order is located in one place. However, after several releases, the class becomes very large and difficult to understand. Every developer working on a new feature modifies the same file, making maintenance increasingly challenging.

Problem The Order class now performs multiple unrelated tasks. It calculates bills, saves order details to the database, sends confirmation emails, generates invoices, logs transactions, and prints reports. Each of these responsibilities belongs to a different part of the application, yet they are all combined into a single class.

As business requirements continue to change, developers repeatedly modify the same class. Even a small change to one feature requires testing the entire class because every responsibility is tightly connected. Over time, the class becomes difficult to maintain, understand, and extend.

Pain Points

Because all responsibilities are placed inside one class, every modification increases the possibility of introducing new bugs. Developers working on invoice generation may accidentally affect email functionality. Testing becomes more time-consuming because unrelated features cannot be tested independently. The class gradually grows into hundreds of lines of code, making debugging and maintenance increasingly difficult. Team collaboration also becomes harder because multiple developers frequently modify the same file, leading to merge conflicts and reduced productivity.

Solution

The Single Responsibility Principle states that a class should have only one responsibility and therefore only one reason to change.

Instead of combining multiple responsibilities into one class, each responsibility should be moved into its own dedicated class. Order calculation should be handled by an OrderCalculator, invoice generation by an InvoiceService, email notifications by an

EmailService, and database operations by an OrderRepository. Each class focuses on a single task, making the overall design cleaner, easier to understand, and simpler to maintain.

Java Program 1 – Bad Code (SRP Violation)

Java Program 2 – Good Code (SRP Applied)

Benefits

Applying the Single Responsibility Principle makes software easier to understand because each class performs only one well-defined task. Changes remain isolated within individual classes, reducing the risk of affecting unrelated functionality. Smaller classes are easier to

A class should have one reason to change. Split unrelated jobs apart.

// BAD: one class does business logic AND persistence AND formatting
class Invoice {
    double total;
    void save() { /* DB code */ }
    String toPdf() { /* rendering */ return ""; }
}

// GOOD: each class owns a single responsibility
class Invoice { double total; }
class InvoiceRepository { void save(Invoice i) { /* DB code */ } }
class InvoicePrinter { String toPdf(Invoice i) { return ""; } }