單一職責(zé)原則（SRP）要求一個(gè)類(lèi)只負(fù)責(zé)一項(xiàng)功能，如將訂單處理中的保存和郵件發(fā)送分離；2. 開(kāi)閉原則（OCP）要求對(duì)擴(kuò)展開(kāi)放、對(duì)修改關(guān)閉，如通過(guò)Shape接口實(shí)現(xiàn)新增圖形無(wú)需修改計(jì)算器；3. 里氏替換原則（LSP）要求子類(lèi)能替換父類(lèi)而不破壞程序，如用獨(dú)立類(lèi)避免正方形繼承矩形導(dǎo)致的行為異常；4. 接口隔離原則（ISP）要求客戶端不應(yīng)依賴不需要的接口，如拆分多功能設(shè)備接口為獨(dú)立的打印、掃描、傳真接口；5. 依賴倒置原則（DIP）要求高層模塊不依賴低層模塊，兩者都依賴抽象，如OrderService依賴Database接口而非具體實(shí)現(xiàn)。這五個(gè)原則共同提升Java代碼的可維護(hù)性、可擴(kuò)展性和可測(cè)試性。

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 refactor. 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 instanceof Circle) {
                Circle c = (Circle) shape;
                total = Math.PI * c.radius * c.radius;
            } else if (shape instanceof 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 violated. 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 maintainable 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 concretions.

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 violated.

以上是為Java開(kāi)發(fā)人員解釋的堅(jiān)實(shí)原則的詳細(xì)內(nèi)容。更多資訊請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！