Understanding SOLID Design Principles: A Comprehensive Guide

In the world of software development, creating code that not only works but is also maintainable, flexible, and scalable is a constant pursuit. As software systems grow in complexity, maintaining them becomes increasingly challenging. This is where SOLID design principles come to the rescue.
SOLID is an acronym that represents a set of five fundamental principles of object-oriented programming and design. When applied effectively, these principles can significantly improve the quality of your code and make it easier to manage, extend, and modify. SOLID is not just a catchy term, it’s a guide to writing software that stands the test of time.
This comprehensive guide will delve deep into the world of SOLID design principles. We’ll explore what each principle entails, why they matter, and how they can be applied in real-world software development scenarios. Whether you are a seasoned developer looking to reinforce your design skills or a newcomer eager to grasp the essentials of writing clean and maintainable code, this blog is for you.

The Five SOLID Principles

Before we dive in, let’s briefly introduce the five SOLID principles:

Single Responsibility Principle (SRP): A class should have only one reason to change, meaning it should have a single responsibility.
Open-Closed Principle (OCP): Software entities (e.g. classes, modules) should be open for extension but closed for modification.
Liskov Substitution Principle (LCP): Subtypes must be substitutable for their base types without altering the correctness of the program.
Interface Segregation Principle (ISP): Clients should not be forced tp depend on interfaces they do not use.
Dependency Inversion Principle (DIP): 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.

Each of these principles serves as a building block for creating robust and maintainable software, and understanding them is key to becoming a proficient software developer.

Single Responsibility Principle (SRP)

The Single Responsibility Principle (SRP) is the first of the SOLID design principles. It states that a class should have only one reason to change, meaning it should have a single responsibility. In other words, a class should encapsulate a single, well-defined piece of functionality. This principle helps in making your code more maintainable, understandable, and easier to extend.

Why SRP matters

When a class has multiple responsibilities, it becomes tightly coupled to different parts of your application. This makes it more challenging to maintain and test. If one responsibility changes, it can affect the entire class, potentially introducing bugs or requiring changes in unrelated areas. By adhering to SRP, you create classes that are more modular and less prone to unintended consequences.
Let’s explore an example to demonstrate SRP in action. We’ll create a simple payroll system that calculates employee salaries and generates payroll reports.


public class PayrollSystem {
    private List<Employee> employees;

    public PayrollSystem(List<Employee> employees) {
        this.employees = employees;
    }

    public void calculateSalaries() {
        // Calculate salaries for all employees and update their records
        for (Employee employee : employees) {
            double salary = employee.getBaseSalary() + employee.getBonus();
            employee.setSalary(salary);
        }
    }

    public void generatePayrollReport() {
        // Generate a payroll report based on employee data
        // and save it to a file or send it via email
        // ...
    }
    
    // Other methods related to payroll management...
}

In the above example, the PayrollSystem class handles both salary calculation and report generation. This violates SRP because it combines two distinct responsibilities.
To adhere to SRP, we’ll separate the responsibilities into two classes:
SalaryCalculator for salary calculation and PayrollReporter for report generation.


public class SalaryCalculator {
    public void calculateSalaries(List<Employee> employees) {
        // Calculate salaries for all employees and update their records
        for (Employee employee : employees) {
            double salary = employee.getBaseSalary() + employee.getBonus();
            employee.setSalary(salary);
        }
    }
}

public class PayrollReporter {
    public void generatePayrollReport(List<Employee> employees) {
        // Generate a payroll report based on employee data
        // and save it to a file or send it via email
        // ...
    }
}

public class Employee {
    private String name;
    private double baseSalary;
    private double bonus;
    private double salary;

    public Employee(String name, double baseSalary, double bonus) {
    		this.name = name;
		this.baseSalary = baseSalary;
		this.bonus = bonus;
	}

	public String getName(){ return this.name; }
	public double getBaseSalary(){ return this.baseSalary; }
	public double getBonus() {return this.bonus; }
	public void setSalary(double salary){ 
this.salary = salary
}

public double getSalary(){
	return this.salary;
}

}

public class Main {
    public static void main(String[] args) {
        // Create a list of employees
        List<Employee> employees = new ArrayList<>();
        employees.add(new Employee("Alice", 50000, 2000));
        employees.add(new Employee("Bob", 60000, 2500));
        
        // Initialize instances of SalaryCalculator and PayrollReporter
        SalaryCalculator salaryCalculator = new SalaryCalculator();
        PayrollReporter payrollReporter = new PayrollReporter();
        
        // Calculate salaries using SalaryCalculator
        salaryCalculator.calculateSalaries(employees);
        
        // Generate payroll reports using PayrollReporter
        payrollReporter.generatePayrollReport(employees);
    }
}

In the refactored code:

The SalaryCalculator class is responsible for calculating employee salaries.
The PayrollReporter class is responsible for generating payroll reports.
Each class has a single, well-defines responsibility, adhering to SRP.
The Main class demonstrates how to use these classes to calculate salaries and generate payroll reports.

By adhering to SRP, this code is more modular and easier to maintain. Changes to salary calculation logic won’t impact report generation, and vice-versa. It also allows for better testing and future extensibility of the payroll system.

Open-Closed Principle (OCP)

The Open-Closed Principle (OCP) is the second principle in the SOLID design principles. It states that software entities (such as classes, modules, and functions) should be open for extension but closed for modification. In other words, you should be able to add new functionality to a system without altering its existing source code.

Why OCP matters

OCP promotes a design that is both flexible and maintainable. When you adhere to this principle, you can introduce new features or make changes to your software without the risk of introducing bugs or affecting existing, working code. It encourages modular and reusable code, making your software more robust and adaptable.
Let's illustrate OCP with a code example involving shapes and their area calculation


public abstract class Shape {
    // Common properties and methods for all shapes...

    public abstract double calculateArea();
}

public class Circle extends Shape {
    private double radius;

    public Circle(double radius) {
        this.radius = radius;
    }

    @Override
    public double calculateArea() {
        return Math.PI * radius * radius;
    }
}

public class Rectangle extends Shape {
    private double width;
    private double height;

    public Rectangle(double width, double height) {
        this.width = width;
        this.height = height;
    }

    @Override
    public double calculateArea() {
        return width * height;
    }
}

// Usage
public class Main {
    public static void main(String[] args) {
        Circle circle = new Circle(5);
        Rectangle rectangle = new Rectangle(4, 6);
        
        System.out.println("Circle area: " + circle.calculateArea());
        System.out.println("Rectangle area: " + rectangle.calculateArea());
    }
}

The above code has the following issues:

Lack of Extensibility: Adding a new shape (e.g., Triangle) would require modifying the existing codebase. This violates the OCP principle, which states that the code should be open for extension without modifying existing code.
Code Duplication: The area calculation logic for each shape (e.g., Circle and Rectangle) is embedded within their respective classes. If you add a new shape, you'd need to duplicate this pattern, which leads to code redundancy and maintenance challenges.
Coupling of Concerns: The code combines the concerns of representing a shape (e.g., defining properties and constructors) with the concern of calculating its area. This results in a lack of separation of concerns and makes the code less modular.
Difficulty in testing: Testing the area calculation logic becomes challenging because it’s tightly coupled with shape classes. This makes it difficult to isolate and test individual components independently.

In essence, the original code violates the OCP because it's not designed to accommodate future changes or additions to the system without modifying existing classes. It lacks the flexibility and extensibility needed in a well-designed software system. Refactoring the code to adhere to OCP, as demonstrated in the refactored example, addresses these issues and provides a more maintainable and extensible solution.

Refactored Code (Adhering to OCP)

To adhere to the Open-Closed Principle, we'll introduce an interface for area calculation (AreaCalculatable) and a separate class (AreaCalculator) responsible for calculating areas. This allows us to add new shapes without modifying existing code.


public interface AreaCalculatable {
    double calculateArea();
}

public class Circle implements AreaCalculatable {
    private double radius;

    public Circle(double radius) {
        this.radius = radius;
    }

    @Override
    public double calculateArea() {
        return Math.PI * radius * radius;
    }
}

public class Rectangle implements AreaCalculatable {
    private double width;
    private double height;

    public Rectangle(double width, double height) {
        this.width = width;
        this.height = height;
    }

    @Override
    public double calculateArea() {
        return width * height;
    }
}

public class AreaCalculator {
    public double calculateArea(AreaCalculatable shape) {
        return shape.calculateArea();
    }
}

// Usage
public class Main {
    public static void main(String[] args) {
        Circle circle = new Circle(5);
        Rectangle rectangle = new Rectangle(4, 6);
        
        AreaCalculator areaCalculator = new AreaCalculator();
        
        System.out.println("Circle area: " + areaCalculator.calculateArea(circle));
        System.out.println("Rectangle area: " + areaCalculator.calculateArea(rectangle));
    }
}

In the refactored code:

We introduce the ‘AreaCalculatable’ interface for shapes that can calculate their areas.
Each shape class implements this interface and provides its own calculation logic.
The ‘AreaCalculator’ class calculates the area of any shape that implements the ‘AreaCalculatable’ interface.

With this design, adding a new shape (e.g. ‘Triangle’) is as simple as creating a new class that implements the ‘AreaCalculatable’ interface, without needing to modify the ‘AreaCalculator’ or existing shape classes. This demonstrates how adhering to the Open-Closed Principle leads to a more extensible and maintainable codebase.

Liskov Substitution Principle (LSP)

According to LSP, the objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program.
In simple terms, if a class B is a subclass of class A, you should be able to use objects of class B wherever you use objects of class A without causing issues.

Why LSP matters

LSP promotes the idea of substitutability and inheritance. When you adhere to this principle, you ensure that derived classes don’t violate the expected behavior of the base class, leading to a more maintainable and predictable code. Violations of LSP can result in unexpected and erroneous behavior in your code.
Let’s understand this principle with an example


public class Animal {
   public void eatGrass() throws Exception {
       System.out.println("I'm an animal and I eat Grass!!!");
   }

}

public class Horse extends Animal {
   public void eatGrass() {
       System.out.println("I'm a Horse and I'm eating Grass.");
   }

}

public class Lion extends Animal{
   @Override
   public void eatGrass() throws Exception {
       throw new Exception("Hey!!! I won't eat Grass.");
   }
}

public class AnimalDemo {
   public static void main(String[] args) throws Exception {
       Animal maximusTheHorse = new Horse();

       System.out.println("Maximus, The Horse: ");
       maximusTheHorse.eatGrass();

       Animal simbaTheLion = new Lion();

       System.out.println("Simba, The Lion: ");
       simbaTheLion.eatGrass(); // This doesn't seem right, does it ?
   }

}

The above code violates LSP and here’s why

Change in Behavior: The Lion class overrides the eatGrass method from the base class Animal and changes its behavior. In the base class, it's expected that the method will eat grass, but in the derived Lion class, it throws an exception indicating that lions won't eat grass. This change in behavior violates the principle of substitutability.
Exception Thrown: The base class Animal declares that the eatGrass method throws an exception, but the derived Lion class omits the exception declaration. This violates the "Liskov Substitution Principle," which states that a derived class should not strengthen preconditions (in this case, adding an exception that wasn't present in the base class).

To adhere to the Liskov Substitution Principle, you should ensure that derived classes do not modify the behavior of base class methods in a way that violates client expectations. If a method is declared in the base class with a certain behavior, derived classes should maintain or refine that behavior but not change it incompatibly.

Refactored Code (Adhering to LSP)

First we will convert the class Animal to abstract class.


public abstract class Animal {
   public abstract void eat();
}

Then we will create 2 more abstract classes. One for herbivorous and another for carnivorous and each of these classes will extend from abstract class A


public abstract class Herbivore extends Animal {
   public void eat() {
       this.eatGrass();
   }
   public abstract void eatGrass();
}

public abstract class Carnivore extends Animal {
   @Override
   public void eat() {
       this.eatMeat();
   }
   public abstract void eatMeat();
}

Now we will create individual animal classes such as Horse and Lion which will extend from Herbivore or Carnivore abstract classes depending on their eating habits.


public class Horse extends Herbivore {
   public void eatGrass() {
       System.out.println("I'm a Horse and I'm eating Grass.");
  }
}
public class Lion extends Carnivore {
   @Override
   public void eatMeat() {
       System.out.println("I'm a Lion and I'm eating Meat!!!");
   }
}
And finally our AnimalDemo class which is our main class.
public class AnimalDemo {
   public static void main(String[] args) {
       Animal simba = new Lion();
       Animal maximus = new Horse();

       simba.eat();
       maximus.eat();
}
}

Output:

I'm a Lion and I'm eating Meat!!!

I'm a Horse and I'm eating Grass.

Here you can see that the code is more readable and maintainable. So if we want to add more animals like the Giraffe, Leopard, and Tiger then we can simply extend them from the abstract classes Carnivore or Herbivore depending on their eating habits without any issues.

Interface Segregation Principle

The Interface Segregation Principle (ISP) is one of the SOLID principles of object-oriented design. It suggests that a class should not be forced to implement interfaces it doesn't use. In other words, clients should not be compelled to depend on interfaces they do not need. This principle aims to prevent classes from being overloaded with unnecessary methods and promotes the creation of lean, focused interfaces.

Why ISP matters

The ISP helps to keep interfaces small, focused, and cohesive, which leads to better maintainability and flexibility in your software. When you adhere to this principle, changes to one part of your codebase won't affect unrelated parts. It also promotes better code organization and easier testing.
Let's explore the ISP using a code example involving a DocumentProcessor that handles various document types (e.g., Word documents and PDFs). Initially, we'll create a single, bloated interface, and then refactor it to adhere to the ISP.

Original Code (Violating ISP)

In the initial code, we have a single Document interface with methods for editing, saving, and printing documents. However, not all document types support these operations.


public interface Document {
    void edit();
    void save();
    void print();
}

public class WordDocument implements Document {
    // Implementation for Word documents
    public void edit() {
        // Edit the document...
    }

    public void save() {
        // Save the document...
    }

    public void print() {
        // Print the document...
    }
}

public class PdfDocument implements Document {
    // Implementation for PDF documents
    public void edit() {
        // Unsupported operation for PDFs, but must be implemented...
    }

    public void save() {
        // Save the document...
    }

    public void print() {
        // Print the document...
    }
}

In this code:

The Document interface contains methods that are not applicable to all document types (e.g., edit for PDFs).
The PdfDocument class is forced to implement methods that it shouldn't support, violating ISP.

Refactored Code (Adhering to ISP)

To adhere to the Interface Segregation Principle, we'll split the Document interface into smaller, more focused interfaces tailored to each document type.


// Separate interfaces for each document type
public interface EditableDocument {
    void edit();
}

public interface SavableDocument {
    void save();
}

public interface PrintableDocument {
    void print();
}

public class WordDocument implements EditableDocument, SavableDocument, PrintableDocument {
    // Implementation for Word documents
    public void edit() {
        // Edit the document...
    }

    public void save() {
        // Save the document...
    }

    public void print() {
        // Print the document...
    }
}

public class PdfDocument implements SavableDocument, PrintableDocument {
    // Implementation for PDF documents
    public void save() {
// Save the document...
    }

    public void print() {
        // Print the document...
    }
}

In the refactored code,

We've split the Document interface into separate interfaces (EditableDocument, SavableDocument, and PrintableDocument) to represent specific document capabilities.
Each document class implements only the interfaces that are relevant to its functionality.

This design adheres to the Interface Segregation Principle by allowing each document type to implement only the methods that are appropriate for its behavior. Clients can now depend on specific interfaces they need, reducing unnecessary coupling and promoting a more modular and maintainable codebase.

Dependency Inversion Principle

The Dependency Inversion Principle (DIP) is one of the SOLID principles of object-oriented design. It states that high-level modules should not depend on low-level modules; both should depend on abstractions. In other words, software modules (such as classes or components) should rely on abstract interfaces or classes rather than concrete implementations.
Additionally, abstractions should not depend on details; details should depend on abstractions.

Why DIP matters

DIP promotes flexibility, extensibility, and easier maintenance in software systems. By adhering to this principle, you can change the behavior of a component without modifying its high-level modules. It also encourages the use of interfaces and abstractions, making it easier to replace or extend components.
Let's explore the DIP using a code example involving a messaging system. Initially, we'll create a system that violates DIP by directly depending on concrete messaging services. Then, we'll refactor it to adhere to DIP by introducing abstractions and dependency injection.
In the initial code, we have a MessagingSystem class that sends messages using concrete messaging services (EmailService and SMSService). This violates DIP because the high-level MessagingSystem depends on specific low-level implementations.


public class MessagingSystem {
    private EmailService emailService = new EmailService();
    private SMSService smsService = new SMSService();

    public void sendEmailMessage(String to, String message) {
        emailService.sendEmail(to, message);
    }

    public void sendSMSMessage(String to, String message) {
        smsService.sendSMS(to, message);
    }
}

public class EmailService {
    public void sendEmail(String to, String message) {
        // Send an email...
    }
}

public class SMSService {
    public void sendSMS(String to, String message) {
        // Send an SMS...
    }
}

In this code

The MessagingSystem directly depends on concrete services (EmailService and SMSService), violating DIP.
If you want to change the messaging services or add new ones, you'd need to modify the MessagingSystem class, which is inflexible.

To adhere to the Dependency Inversion Principle, we'll refactor the code by introducing abstractions (MessageService interface) and using dependency injection to provide service implementations.


// Abstraction for message services
public interface MessageService {
    void sendMessage(String to, String message);
}

// Concrete implementations of message services
public class EmailService implements MessageService {
    @Override
    public void sendMessage(String to, String message) {
        // Send an email...
    }
}

public class SMSService implements MessageService {
    @Override
    public void sendMessage(String to, String message) {
        // Send an SMS...
    }
}

// MessagingSystem depends on abstractions (DIP adhered)
public class MessagingSystem {
    private MessageService messageService;

    // Dependency injection of the message service
    public MessagingSystem(MessageService messageService) {
        this.messageService = messageService;
    }

    public void sendMessage(String to, String message) {
        messageService.sendMessage(to, message);
    }
}

In the refactored code:

We introduce the MessageService interface, which defines the contract for sending messages.
Concrete message services (EmailService and SMSService) implement this interface.
The MessagingSystem class depends on the MessageService abstraction through dependency injection. It no longer relies on specific implementations.

By adhering to DIP, we decouple high-level modules from low-level implementations, making it easier to change or extend the messaging system. New message services can be added without modifying the MessagingSystem class, promoting flexibility and maintainability.

‍

Hi, I am Ankit Pradhan. I am a Java backend developer specialized in Spring Framework. In love with solving business related problems with the help of code. In my free time, you will either find me watching a thriller movie or reading a technical blog.

Understanding SOLID Design Principles: A Comprehensive Guide