The single responsibility principle (SRP) requires a class to be responsible for only one function, such as separating the saving and mail sending in order processing; 2. The opening and closing principle (OCP) requires opening and closing for extensions and closing for modifications, such as adding new graphics through the Shape interface without modifying the calculator; 3. The Richter replacement principle (LSP) requires that subclasses can replace the parent class without destroying the program, such as using independent classes to avoid behavior abnormalities caused by square inheritance rectangles; 4. The interface isolation principle (ISP) requires that clients should not rely on unwanted interfaces, such as splitting the multi-function device interface to independent printing, scanning, and fax interfaces; 5. The dependency inversion principle (DIP) requires that high-level modules do not rely on low-level modules, and both rely on abstractions, such as OrderService depends on Database interface rather than concrete implementation. These five principles jointly improve the maintainability, extensibility and testability of Java code.

The SOLID principles are a set of five design principles intended to make software designs more understandable, flexible, and maintainable—especially in object-oriented programming. For Java developers, applying SOLID helps build systems that are easier to extend, test, and reflector. Let's break down each principle with practical Java examples and clear explanations.

1. Single Responsibility Principle (SRP)

A class should have only one reason to change.

In other words, a class should be responsible for a single part of the application's functionality. If a class handles multiple tasks, changing one might break the other.

Example (Violation):

 public class OrderProcessor {
    public void processOrder(Order order) {
        // Save order to database
        saveToDatabase(order);

        // Send confirmation email
        sendEmail(order.getCustomerEmail());
    }

    private void saveToDatabase(Order order) { /* ... */ }
    private void sendEmail(String email) { /* ... */ }
}

Here, OrderProcessor handles both data persistence and communication—two responsibilities.

Refactored (SRP Compliant):

 public class OrderRepository {
    public void save(Order order) { /* ... */ }
}

public class EmailService {
    public void sendConfirmation(String email) { /* ... */ }
}

public class OrderProcessor {
    private OrderRepository repository;
    private EmailService emailService;

    public void processOrder(Order order) {
        repository.save(order);
        emailService.sendConfirmation(order.getCustomerEmail());
    }
}

Now each class has a single job. Changes to email logic won't affect data saving.

2. Open/Closed Principle (OCP)

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

You should be able to add new functionality without changing existing code.

Example (Violation):

 public class AreaCalculator {
    public double calculateArea(List<Object> shapes) {
        double total = 0;
        for (Object shape : shapes) {
            if (shape instance of Circle) {
                Circle c = (Circle) shape;
                total = Math.PI * c.radius * c.radius;
            } else if (shape instance of Rectangle) {
                Rectangle r = (Rectangle) shape;
                total = r.width * r.height;
            }
        }
        return total;
    }
}

Every time you add a new shape, you must modify this method.

Refactored (OCP Compliant):

 public interface Shape {
    double area();
}

public class Circle implements Shape {
    private double radius;
    public double area() { return Math.PI * radius * radius; }
}

public class Rectangle implements Shape {
    private double width, height;
    public double area() { return width * height; }
}

public class AreaCalculator {
    public double calculateArea(List<Shape> shapes) {
        return shapes.stream()
                     .mapToDouble(Shape::area)
                     .sum();
    }
}

Now you can add new shapes (eg, Triangle) without touching AreaCalculator .

3. Liskov Substitution Principle (LSP)

Subtypes must be substitutable for their base types without altering the correctness of the program.

If a class inherits from another, it should not break the expected behavior.

Example (Violation):

 public class Rectangle {
    protected int width, height;

    public void setWidth(int width) { this.width = width; }
    public void setHeight(int height) { this.height = height; }

    public int getArea() { return width * height; }
}

public class Square extends Rectangle {
    @Override
    public void setWidth(int width) {
        super.setWidth(width);
        super.setHeight(width);
    }

    @Override
    public void setHeight(int height) {
        super.setHeight(height);
        super.setWidth(height);
    }
}

Now, if a method expects a Rectangle and sets width and height independently, using a Square breaks that assumption.

Better Approach: Avoid inheritance when behavior contracts are violent. Use composition or separate hierarchies.

 public interface Shape {
    int area();
}

public class Rectangle implements Shape {
    private int width, height;
    // setters and area()
}

public class Square implements Shape {
    private int side;
    // area = side * side
}

Now, no misleading inheritance. LSP is preserved.

4. Interface Segregation Principle (ISP)

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

Big, monolithic interfaces make classes implement methods they don't need.

Example (Violation):

 public interface Machine {
    void print();
    void scan();
    void fax();
}

public class OldPrinter implements Machine {
    public void print() { System.out.println("Printing"); }
    public void scan() { throw new UnsupportedOperationException(); }
    public void fax() { throw new UnsupportedOperationException(); }
}

OldPrinter is forced to implement irrelevant methods.

Refactored (ISP Compliant):

 public interface Printer {
    void print();
}

public interface Scanner {
    void scan();
}

public interface FaxMachine {
    void fax();
}

public class OldPrinter implements Printer {
    public void print() { System.out.println("Printing"); }
}

public class MultiFunctionDevice implements Printer, Scanner, FaxMachine {
    public void print() { /* ... */ }
    public void scan() { /* ... */ }
    public void fax() { /* ... */ }
}

Now, classes implement only what they support.

5. Dependency Inversion Principle (DIP)

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

Also: Abstractions should not depend on details. Details should depend on abstractions.

This enables loose coupling and easier testing.

Example (Violation):

 public class OrderService {
    private MySQLDatabase database = new MySQLDatabase();

    public void saveOrder(Order order) {
        database.save(order);
    }
}

OrderService is tightly coupled to MySQLDatabase . Hard to test or switch databases.

Refactored (DIP Compliant):

 public interface Database {
    void save(Order order);
}

public class MySQLDatabase implements Database {
    public void save(Order order) { /* ... */ }
}

public class OrderService {
    private Database database;

    public OrderService(Database database) {
        this.database = database;
    }

    public void saveOrder(Order order) {
        database.save(order);
    }
}

Now OrderService depends on the Database interface. You can inject any implementation (MySQL, PostgreSQL, Mock, etc.).

Used with dependency injection frameworks (like Spring), this becomes even more powerful.

Final Thoughts

SOLID principles aren't rigid rules—they're guidelines to help you write cleaner, more maintained Java code. Applying them early can save you from technical debt later.

• SRP : One job per class.
• OCP : Extend, don't modify.
• LSP : Subclasses shouldn't surprise users.
• ISP : Small, focused interfaces.
• DIP : Depend on abstractions, not concretes.

They might feel like overkill at first, especially in small projects. But as your codebase grows, these principles become essential tools for managing complexity.

Basically, if your Java classes are hard to test, change, or reuse—chances are, one or more SOLID principles are being violent.

The above is the detailed content of The SOLID Principles Explained for Java Developers. For more information, please follow other related articles on the PHP Chinese website!