Understanding SOLID Principles with Real-Time Code Examples in Java

The SOLID principles are a set of five design principles in object-oriented programming and design that aim to make software designs more understandable, flexible, and maintainable. The acronym SOLID stands for:

1. Single Responsibility Principle (SRP)
2. Open/Closed Principle (OCP)
3. Liskov Substitution Principle (LSP)
4. Interface Segregation Principle (ISP)
5. Dependency Inversion Principle (DIP)

In this blog post, we’ll delve into each of the SOLID principles and provide real-time code examples in Java to illustrate them.

1. Single Responsibility Principle (SRP)

Definition: A class should have only one reason to change, meaning it should have only one responsibility.

Explanation: Each class or module should focus on doing one thing and doing it well. It should have a single responsibility and not take on additional responsibilities that belong to other classes.

Real-Time Example: Let’s consider a class responsible for Book operations.

class Book {
    public void printBookDetails() {
        // Code to print book details
    }
}

class BookStore {
    public void sellBook() {
        // Code to sell a book
    }
}

class BookInventory {
    public void updateInventory() {
        // Code to update book inventory
    }
}

In this example, Book is responsible for printing book details, BookStore is responsible for selling books, and BookInventory is responsible for updating inventory. Each class does only one thing, following the Single Responsibility Principle.

2. Open/Closed Principle (OCP)

Definition: Classes should be open for extension but closed for modification.

Explanation: You should be able to add new functionality to a system without changing the existing code. This principle encourages you to design your classes in a way that allows for easy extension and modification without altering the existing codebase.

Real-Time Example: Consider a Shape interface and its implementations.

interface Shape {
    double calculateArea();
}

class Circle implements Shape {
    private double radius;
    public Circle(double radius) {
        this.radius = radius;
    }
    @Override
    public double calculateArea() {
        return Math.PI * radius * radius;
    }
}
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;
    }
}
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;
    }
}

In this example, the Shape interface is open for extension with the addition of new shapes like Triangle but closed for modification as the existing Circle and Rectangle classes remain unchanged.

3. Liskov Substitution Principle (LSP)

Definition: Objects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program.

Explanation: Subtypes must be substitutable for their base types without altering the correctness of the program. In other words, you should be able to use a subclass wherever its superclass is used without causing unexpected behavior.

Real-Time Example: Consider a Rectangle class and its Square subclass.

class Rectangle {
    protected int width;
    protected int height;

public Rectangle(int width, int height) {
        this.width = width;
        this.height = height;
    }
    // getters, setters, and other methods
}
class Square extends Rectangle {
    public Square(int size) {
        super(size, size);
    }
    @Override
    public void setWidth(int width) {
        super.setWidth(width);
        super.setHeight(width);
    }
    @Override
    public void setHeight(int height) {
        super.setWidth(height);
        super.setHeight(height);
    }
}

In this example, Square is a subclass of Rectangle. According to LSP, you should be able to substitute Rectangle objects with Square objects without any unexpected behavior. However, if Square overrides the setWidth() or setHeight() methods to maintain square properties, it violates LSP.

4. Interface Segregation Principle (ISP)

Definition: Clients should not be forced to implement interfaces they don’t use.

Explanation: Instead of having a single large interface, you should create smaller, more specific interfaces. Clients should not be forced to implement methods they do not use, and interfaces should be tailored to specific sets of behaviors.

Real-Time Example: Consider a Document interface and its implementations.

interface ReadableDocument {
    void read();
}

interface WritableDocument {
    void write();
}
interface PrintableDocument {
    void print();
}
class Document implements ReadableDocument, WritableDocument, PrintableDocument {
    @Override
    public void read() {
        // Code to read document
    }
    @Override
    public void write() {
        // Code to write document
    }
    @Override
    public void print() {
        // Code to print document
    }
}

In this example, instead of having a single large Document interface, we have separate smaller interfaces (ReadableDocument, WritableDocument, PrintableDocument) that the Document class can implement.

5. Dependency Inversion Principle (DIP)

Definition: High-level modules should not depend on low-level modules. Both should depend on abstractions.

Explanation: Abstractions should not depend on details; rather, details should depend on abstractions. High-level modules, which contain complex logic, should not depend on low-level modules. Both should depend on abstractions, such as interfaces or abstract classes, to reduce coupling and increase flexibility.

Real-Time Example: Consider a PaymentProcessor class and its dependency on a payment gateway.

// Dependency Inversion Principle
interface PaymentGateway {
    void processPayment();
}

class PayPalPayment implements PaymentGateway {
    @Override
    public void processPayment() {
        // Code to process payment using PayPal
    }
}

class PaymentProcessor {
    private PaymentGateway paymentGateway;

    public PaymentProcessor(PaymentGateway paymentGateway) {
        this.paymentGateway = paymentGateway;
    }

    public void processPayment() {
        paymentGateway.processPayment();
    }
}

In this example, PaymentProcessor depends on the PaymentGateway interface instead of a specific payment gateway implementation like PayPalPayment. This allows you to easily switch between different payment gateways by providing a different implementation of the PaymentGateway interface.

By understanding and applying the SOLID principles, you can create more maintainable, extensible, and loosely-coupled software systems. These principles help in achieving better code organization, reducing dependencies, and improving code reusability and scalability.

Thanks & Happy Learning :)