Master SOLID Principles in java in Minutes !

In the world of object-oriented programming, there are certain design principles that can greatly enhance the quality of our software.
One such set of principles is known as SOLID, an acronym coined by Michael Feathers that stands for Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion.
These principles, introduced by Robert C. Martin, have revolutionized the way we write code and have become essential knowledge for any developer.

In this comprehensive guide, we will dive deep into each of the SOLID principles and explore how they can be applied in the context of Java programming.
We will provide clear explanations and practical examples to help you understand and implement these principles in your own projects.

So, let’s get started!

Introduction to SOLID Principles
- The Purpose of SOLID Principles
- Benefits of Using SOLID Principles
Single Responsibility Principle (SRP)
Open/Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)
Combining the SOLID Principles
- Applying SOLID Principles in Real-Life Scenarios
Conclusion

Introduction to SOLID Principles

The SOLID principles of object-oriented design were introduced by Robert C. Martin and later expanded upon by Michael Feathers.
These principles aim to improve the maintainability, understandability, and flexibility of software systems.
By adhering to these principles, developers can create code that is easier to test, less prone to bugs, and more adaptable to changing requirements.

The Purpose of SOLID Principles

The SOLID principles provide guidelines for designing software that is modular, loosely coupled, and easily extensible.
They help us write code that is more resilient to change and promotes good software engineering practices.
By following these principles, we can build systems that are easier to understand, maintain, and modify.

Benefits of Using SOLID Principles

By applying the SOLID principles in your codebase, you can reap several benefits:

Improved Testability: Code that follows SOLID principles is easier to test because it is organized into smaller, focused units.
This makes it simpler to write unit tests that target specific behavior.
Reduced Coupling: SOLID principles promote loose coupling between modules, making it easier to change one module without affecting others.
This enhances code maintainability and allows for greater flexibility in adapting to new requirements.
Enhanced Code Reusability: By designing code around SOLID principles, you create modules that are more modular and self-contained.
This makes it easier to reuse these modules in other parts of your application or in different projects altogether.
Improved Code Readability: SOLID principles encourage the separation of concerns, resulting in code that is easier to read and understand.
When each module has a single responsibility, it becomes easier to reason about its behavior.
Flexibility and Adaptability: SOLID principles help you build code that is more resistant to changes in requirements.
By designing your code to be open for extension but closed for modification, you can easily introduce new features without modifying existing code.

Now that we have a good understanding of the purpose and benefits of SOLID principles, let’s explore each principle in detail.

Single Responsibility Principle (SRP)

The Single Responsibility Principle (SRP) states that a class should have only one reason to change and should be responsible for only one specific aspect of the system’s functionality.
In other words, a class should have a single responsibility and should not have multiple reasons to be modified.

Understanding SRP

The SRP is all about ensuring that each class has a clear and well-defined purpose. When a class has only one responsibility, it becomes easier to understand, test, and maintain.
By separating concerns and delegating responsibilities to other classes, we can achieve a more modular and flexible codebase.

Benefits of SRP

Implementing the SRP in your codebase can lead to several benefits:

Improved Testability: When a class has a single responsibility, it becomes easier to write focused unit tests that target specific behavior.
This improves test coverage and makes it easier to verify the correctness of the code.
Lower Coupling: A class with a single responsibility has fewer dependencies on other classes.
This reduces coupling and makes the codebase more modular, allowing for easier changes and updates.
Better Organization: Smaller, well-organized classes are easier to navigate and understand.
When each class has a clear purpose, it becomes easier to locate and reason about specific functionality.
Easier Maintenance: When a class has only one responsibility, changes in requirements or bug fixes are localized to that specific area.
This makes the codebase more maintainable and reduces the risk of introducing unintended side effects.

Example of Violating SRP

To understand the SRP better, let’s consider an example of a Report class that violates the principle.
Suppose we have the following implementation:

public class Report {
    private String content;

    public Report(String content) {
        this.content = content;
    }

    public void generateReport() {
        // Logic to generate the report content
        System.out.println("Generating the report...");
        // ...
    }

    public void saveToFile() {
        // Logic to save the report content to a file
        System.out.println("Saving the report to a file...");
        // ...
    }

    public void sendEmail() {
        // Logic to send the report via email
        System.out.println("Sending the report via email...");
        // ...
    }
}

In this example, the Report class is responsible for storing report content, saving them to file, and sending email.
This violates the SRP because the class has multiple responsibilities.

Applying SRP

To fix the violation of SRP in the Report class, we can separate each responsibility into a separate class as shown below.

public class Report {
    private String content;

    public Report(String content) {
        this.content = content;
    }

    public String getContent() {
        return content;
    }
}

public class ReportGenerator {
    public void generateReport(Report report) {
        // Logic to generate the report content
        System.out.println("Generating the report...");
        // ...
    }
}

public class ReportSaver {
    public void saveToFile(Report report) {
        // Logic to save the report content to a file
        System.out.println("Saving the report to a file...");
        // ...
    }
}

public class EmailSender {
    public void sendEmail(Report report) {
        // Logic to send the report via email
        System.out.println("Sending the report via email...");
        // ...
    }
}

We have separated the responsibilities as below.

ReportGenerator : Responsibility of generating report.
ReportSaver : Responsibility of saving report.
EmailSender : Responsibility of sending email.

By adhering to the SRP, we have improved the maintainability and testability of our code.
Each class now has a single responsibility, making it easier to understand and modify.

Open/Closed Principle (OCP)

The Open/Closed Principle (OCP) states that classes should be open for extension but closed for modification.
In other words, once a class is defined and implemented, its behavior should be easily extendable without modifying the existing code.

Understanding OCP

The OCP encourages developers to design their code in a way that allows for easy extension without modifying existing code.
This principle promotes the use of abstractions, interfaces, and inheritance to achieve flexibility.

Benefits of OCP

By following the OCP, you can achieve several benefits in your codebase:

Reduced Risk of Bugs: When existing code is not modified, there is a lower risk of introducing new bugs.
Changes and new features can be added through extension, without affecting the stability of the existing code.
Enhanced Code Reusability: By designing code to be open for extension, you create modules that are more modular and reusable.
New features can be added by creating new classes that extend existing ones, without modifying the original code.
Easier Maintenance: When code is designed to be closed for modification, changes can be localized to specific extension points.
This makes the codebase easier to maintain and reduces the risk of introducing unintended side effects.

Example of Violating OCP

To understand the OCP better, let’s consider an example where we violate the principle.

Suppose we have an AreaCalculator class that has methods to calculate areas of rectangle and circle as below

// Updated class violating OCP by modifying existing code
public class AreaCalculator {
    public double calculateRectangleArea(double width, double height) {
        return width * height;
    }

    public double calculateCircleArea(double radius) {
        return Math.PI * radius * radius;
    }

    // New method added for calculating the area of a triangle
    public double calculateTriangleArea(double base, double height) {
        return 0.5 * base * height;
    }
}

Now, let’s say we want to calculate the area of another shape.
Now, we need to directly modify this class to add this feature and we would violate the OCP.

Applying OCP

To adhere to the OCP, instead of using the class, we can use abstraction by creating an interface Shape and implementing different classes for each shape as below

// Interface representing a shape
public interface Shape {
    // implement it for each shape
    double calculateArea();
}

// Rectangle implementation
public class Rectangle implements 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;
    }
}

// Circle implementation
public class Circle implements Shape {
    private double radius;

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

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

// Triangle implementation
public class Triangle implements Shape {
    private double base;
    private double height;

    public Triangle(double base, double height) {
        this.base = base;
        this.height = height;
    }

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

Now, below code can be used to calculate area for different shapes.

public class AreaCalculator {
    public double calculateTotalArea(Shape[] shapes) {
        double totalArea = 0;
        for (Shape shape : shapes) {
            totalArea += shape.calculateArea();
        }
        return totalArea;
    }
}

Now, if we have to add a new shape, existing classes will not be modified.

Hence, by following the OCP, we have made our code more flexible and adaptable to changes in requirements.
New features can be added without modifying existing code, reducing the risk of introducing bugs.

Liskov Substitution Principle (LSP)

The Liskov Substitution Principle (LSP) states that objects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program.
In other words, a subclass should be able to substitute its superclass without changing the behavior of the program.

Understanding LSP

The LSP ensures that subclasses can be used interchangeably with their parent classes.
This principle promotes the use of inheritance and polymorphism to create a more flexible and extensible codebase.

Benefits of LSP

By adhering to the LSP, you can achieve several benefits in your codebase:

Improved Code Reusability: By designing classes that adhere to the LSP, you create a codebase that is more modular and reusable.
Subclasses can be easily substituted for their parent classes, allowing for greater flexibility and code reuse.
Simplified Code Maintenance: When subclasses adhere to the LSP, changes can be localized to specific subclasses without affecting the behavior of the program as a whole.
This simplifies code maintenance and reduces the risk of introducing bugs.
Enhanced Flexibility: The LSP promotes the use of polymorphism, which allows for the creation of code that is more adaptable to changing requirements.
Subclasses can be easily added or modified without affecting the existing codebase.

Example of Violating LSP

To understand the LSP better, let’s consider an example where we violate the principle.
Suppose we have an interface called Bird that defines the behavior of a bird.

public class Bird {
    public void fly() {
        System.out.println("Flying");
    }
}

Now, let’s say we have a class called Ostrich that extends Bird.

public class Ostrich extends Bird {
   // Constructors, getters, and setters

}

// Client code
public class TestBird {
    public static void main(String[] args) {
        Bird ostrich = new Ostrich();
        ostrich.fly(); // This will print "Flying," but ostriches cannot fly
    }
}

In this example, Ostrich class violates the LSP because it an Ostrich cannot fly, causing a disruption in the program’s behavior.

Applying LSP

To adhere to the LSP, we can rework our model to include interfaces that take into account the variations in behavior of different types of birds.
Let’s create an interface Bird

// Interface representing a bird
public interface Bird {
    void fly();
}

Now, we can create separate classes that implement Bird interface and add flying behaviurs for different birds.

// Class representing a generic bird
public class GenericBird implements Bird {
    @Override
    public void fly() {
        System.out.println("Flying");
    }
}

// Class representing an ostrich, implementing Bird
public class Ostrich implements Bird {
    @Override
    public void fly() {
        System.out.println("Ostrich cannot fly");
    }
}

Now the test code will also work fine.

// Client code
public class Client {
  public static void main(String[] args) {
    Bird genericBird = new GenericBird();
    genericBird.fly(); // This will print "Flying"

    Bird ostrich = new Ostrich();
    ostrich.fly(); // This will print "Ostrich cannot fly"
  }
}

By following the LSP, we have created a codebase that is more flexible and adaptable to changes.
Subclasses can be easily added or modified without affecting the existing codebase, promoting code reuse and maintainability.

Interface Segregation Principle (ISP)

The Interface Segregation Principle (ISP) states that clients should not be forced to depend on interfaces they do not use.
In other words, interfaces should be fine-grained and specific to the needs of the clients that use them.

Understanding ISP

The ISP encourages developers to design interfaces that are focused and tailored to the needs of the clients. By creating smaller, more specific interfaces, we can avoid the problems associated with large, monolithic interfaces.

Benefits of ISP

By adhering to the ISP, you can achieve several benefits in your codebase:

Reduced Coupling: Smaller interfaces reduce the coupling between clients and providers, allowing for greater flexibility and modularity.
Clients only need to depend on the methods that are relevant to their needs.
Improved Code Organization: Fine-grained interfaces make it easier to understand and navigate the codebase.
Each interface represents a specific set of behaviors, making it clear what functionality is available to clients.
Enhanced Maintainability: When interfaces are tailored to the needs of clients, changes can be localized to specific interfaces without affecting the behavior of other clients.
This makes the codebase easier to maintain and reduces the risk of introducing bugs.

Example of Violating ISP

To understand the ISP better, let’s consider an example where we violate the principle.
Suppose we have an interface called Worker that outlines the responsibilities of a worker.

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

In this example, a worker is expected to work and eat.
However, if a worker is a robot, then it cannot eat

Applying ISP

To adhere to the ISP, we can split the Worker interface into 2 separate interfaces: Workable and Eatable.

// Interface representing a worker with work action
public interface Workable {
    void work();
}

// Interface representing an eater
public interface Eatable {
    void eat();
}

Now, clients can implement only the interfaces that are relevant to their needs. For example,

// Robot implementing only the Workable interface
public class Robot implements Workable {
    @Override
    public void work() {
        System.out.println("Robot working");
    }
}

// Human implementing both Workable and Eatable interfaces
public class Human implements Workable, Eatable {
    @Override
    public void work() {
        System.out.println("Human working");
    }

    @Override
    public void eat() {
        System.out.println("Human eating");
    }
}

By following the ISP, we have created a codebase that is more modular and focused.
Clients only depend on the methods they require, promoting code reuse and maintainability.

Dependency Inversion Principle (DIP)

The Dependency Inversion Principle (DIP) states that high-level modules should not depend on low-level modules. Instead, both should depend on abstractions.
This principle promotes the use of interfaces or abstract classes to decouple modules and improve code maintainability.

Understanding DIP

The DIP promotes the decoupling of software modules by relying on abstractions instead of concrete implementations.
By depending on abstractions, high-level modules can be easily replaced or extended without modifying the existing code.

Benefits of DIP

By adhering to the DIP, you can achieve several benefits in your codebase:

Reduced Coupling: By depending on abstractions, modules become decoupled from each other, allowing for greater flexibility and modularity.
Changes in one module do not affect the behavior of other modules.
Enhanced Testability: By relying on abstractions, it becomes easier to write tests for high-level modules.
Mocking or stubbing the dependencies becomes simpler, allowing for more focused and effective testing.
Improved Code Maintainability: When modules depend on abstractions, changes to one module do not require modifications to other modules.
This makes the codebase easier to maintain and reduces the risk of introducing bugs.

Example of Violating DIP

To understand the DIP better, let’s consider an example where we violate the principle.
Suppose we have a class called BusinessLogic that represents a business logic.

// High-level module representing a business logic class
public class BusinessLogic {
    private DatabaseConnection databaseConnection;

    public BusinessLogic() {
        this.databaseConnection = new DatabaseConnection();
    }

    public void performBusinessLogic() {
        // Using the DatabaseConnection directly
        databaseConnection.connect();
        // Business logic code
        System.out.println("Performing business logic");
        // Using the DatabaseConnection directly
        databaseConnection.disconnect();
    }
}

// Low-level module representing a database connection class
public class DatabaseConnection {
    public void connect() {
        System.out.println("Connecting to the database");
    }

    public void disconnect() {
        System.out.println("Disconnecting from the database");
    }
}

// Client code
public class Client {
    public static void main(String[] args) {
        BusinessLogic businessLogic = new BusinessLogic();
        businessLogic.performBusinessLogic();
    }
}

In this example, the BusinessLogic class directly creates instances of the DatabaseConnection class using the new keyword. This violates the DIP because the high-level module (BusinessLogic) is directly dependent on low-level module (DatabaseConnection).

Applying DIP

To adhere to the DIP, we can introduce abstractions and use dependency injection to provide the necessary dependencies to the BusinessLogic class.
Let’s create an interface called Connection and modify the BusinessLogic class to depend on this interface:

// Abstraction representing a connection interface
public interface Connection {
  void connect();
  void disconnect();
}

// High-level module representing a business logic class
public class BusinessLogic {
  private Connection connection;

  public BusinessLogic(Connection connection) {
    this.connection = connection;
  }

  public void performBusinessLogic() {
    // Using the Connection abstraction
    connection.connect();
    // Business logic code
    System.out.println("Performing business logic");
    // Using the Connection abstraction
    connection.disconnect();
  }
}

// Low-level module representing a database connection class
public class DatabaseConnection implements Connection {
  @Override
  public void connect() {
    System.out.println("Connecting to the database");
  }

  @Override
  public void disconnect() {
    System.out.println("Disconnecting from the database");
  }
}

By introducing the Connection interface, we have decoupled the BusinessLogic class from the concrete implementation of the database.

By following the DIP, we have improved the flexibility and testability of our codebase.
High-level modules depend on abstractions, promoting code reuse and making the code easier to maintain.

Combining the SOLID Principles

While each of the SOLID principles provides valuable guidance on its own, applying all of them together can lead to even more robust and maintainable code.
By combining the principles, we can create software systems that are modular, flexible, and easy to understand.

Applying SOLID Principles in Real-Life Scenarios

Let’s consider a real-life scenario to demonstrate how the SOLID principles can be applied in combination.

Suppose we are building an online bookstore application where customers can browse and purchase books.
The application consists of the following major components:

Book Management: Responsible for managing the book catalog, including adding, updating, and deleting books.
Shopping Cart: Responsible for managing the customer’s shopping cart, including adding and removing books.
Payment Gateway: Responsible for processing customer payments.

To apply the SOLID principles in this scenario, we can follow these guidelines:

Single Responsibility Principle (SRP): Each component should have a single responsibility.
For example, the Book Management component should be responsible for managing books, while the Shopping Cart component should be responsible for managing the customer’s shopping cart.
Open/Closed Principle (OCP): Each component should be open for extension but closed for modification.
For example, if we want to add a new feature to the Shopping Cart component, such as applying discounts, we can create a new class that extends the existing Shopping Cart class.
Liskov Substitution Principle (LSP): Subclasses should be able to substitute their parent classes without affecting the behavior of the program.
For example, if we have a class called HardcoverBook that extends the Book class, we should be able to use an instance of HardcoverBook wherever a Book object is expected.
Interface Segregation Principle (ISP): Interfaces should be fine-grained and specific to the needs of the clients. For example, the Payment Gateway component should define separate interfaces for processing payments, refunding payments, and querying payment status.
Dependency Inversion Principle (DIP): High-level modules should depend on abstractions, not on low-level modules.
For example, the Book Management component should depend on an interface for accessing the book catalog, allowing for different implementations (e.g., a database or an external API).

By applying the SOLID principles in this scenario, we can create a codebase that is modular, testable, and easy to maintain.
Each component has a clear responsibility, can be easily extended, and depends on abstractions rather than concrete implementations.

Conclusion

In this guide, we have explored the SOLID principles of object-oriented design and their application in Java programming.
We have discussed the Single Responsibility Principle (SRP), Open/Closed Principle (OCP), Liskov Substitution Principle (LSP), Interface Segregation Principle (ISP), and Dependency Inversion Principle (DIP).
By understanding and applying these principles, you can create code that is more maintainable, flexible, and reusable.

Remember, the SOLID principles are not strict rules but rather guidelines to help you design better software.
It’s important to use your judgment and apply these principles where they make sense in your specific context.
By continuously practicing and refining your understanding of these principles, you can become a better software developer and contribute to the creation of high-quality code.

Happy coding and stay SOLID!

SOLID Principles in java(with examples)

Table of Contents