【设计模式】SOLID 设计原则概述

SOLID 是面向对象设计中的五大原则，不管什么面向对象的语言， 这个准则都很重要，如果你没听说过，赶紧先学一下。它可以提高代码的可维护性、可扩展性和可读性，使代码更加健壮、易于测试和扩展。SOLID 代表以下五个设计原则：

1. S - 单一职责原则（Single Responsibility Principle, SRP）
2. O - 开闭原则（Open/Closed Principle, OCP）
3. L - 里氏替换原则（Liskov Substitution Principle, LSP）
4. I - 接口隔离原则（Interface Segregation Principle, ISP）
5. D - 依赖倒置原则（Dependency Inversion Principle, DIP）

---

1. 单一职责原则（SRP）

一个类应该仅有一个引起它变化的原因。
即 一个类应该仅负责一个功能，否则后期修改代码时，可能会影响其他无关功能。

❌ 违反 SRP 的例子

class Report {
public:
    void generateReport() { /* 生成报表 */ }
    void printReport() { /* 打印报表 */ }
    void saveToFile() { /* 保存到文件 */ }
};

问题：
Report 负责 生成报表、打印报表 和 保存报表，违反了 SRP。

✅ 遵循 SRP 的改进

class Report {
public:
    void generateReport() { /* 生成报表 */ }
};

class ReportPrinter {
public:
    void printReport(Report& report) { /* 打印报表 */ }
};

class ReportSaver {
public:
    void saveToFile(Report& report) { /* 保存到文件 */ }
};

改进点：

• Report 只负责生成报表
• ReportPrinter 负责打印
• ReportSaver 负责存储

这样每个类的变更都不会影响其他功能，符合 SRP。

---

2. 开闭原则（OCP）

软件实体（类、模块、函数）应该对扩展开放，对修改关闭。
即：新增功能时，应该通过扩展代码，而不是修改已有代码。

❌ 违反 OCP 的例子

class PaymentProcessor {
public:
    void processPayment(std::string paymentType) {
        if (paymentType == "CreditCard") {
            // 处理信用卡支付
        } else if (paymentType == "PayPal") {
            // 处理 PayPal 支付
        }
    }
};

问题：

• 如果新增 Apple Pay，需要修改 processPayment()，违反 OCP。
• 代码越复杂，修改的风险越高。

✅ 遵循 OCP 的改进

class Payment {
public:
    virtual void pay() = 0;
    virtual ~Payment() = default;
};

class CreditCardPayment : public Payment {
public:
    void pay() override { /* 处理信用卡支付 */ }
};

class PayPalPayment : public Payment {
public:
    void pay() override { /* 处理 PayPal 支付 */ }
};

class PaymentProcessor {
public:
    void processPayment(Payment& payment) {
        payment.pay();
    }
};

改进点：

• 新增支付方式时，不需要修改 PaymentProcessor，只需新增一个类（符合 OCP）。
• 通过 多态 使代码更加灵活。

---

3. 里氏替换原则（LSP）

子类必须能够替换基类，并且不会破坏程序的正确性。

❌ 违反 LSP 的例子

class Bird {
public:
    virtual void fly() { /* 飞行逻辑 */ }
};

class Penguin : public Bird {
public:
    void fly() override {
        throw std::runtime_error("企鹅不会飞！");
    }
};

问题：

• Penguin 继承了 Bird，但企鹅不会飞！
• Penguin::fly() 违背了父类的逻辑，可能导致程序崩溃。

✅ 遵循 LSP 的改进

class Bird {
public:
    virtual void move() = 0;
};

class FlyingBird : public Bird {
public:
    void move() override { /* 飞行逻辑 */ }
};

class Penguin : public Bird {
public:
    void move() override { /* 企鹅走路 */ }
};

改进点：

• 抽象出 FlyingBird 和 Penguin，使 Penguin 不继承 fly()，从而避免违反 LSP。

---

4. 接口隔离原则（ISP）

不应该强迫类实现它们不需要的接口。
即：一个接口不应该承担过多职责，而应该拆分成多个专门的接口。

❌ 违反 ISP 的例子

class Worker {
public:
    virtual void work() = 0;
    virtual void eat() = 0;
};
class Robot : public Worker {
public:
    void work() override { /* 机器人工作 */ }
    void eat() override { throw std::runtime_error("机器人不吃饭！"); }
};

问题：

• Robot 不需要 eat()，但仍然要实现它，违反 ISP。

✅ 遵循 ISP 的改进

class Workable {
public:
    virtual void work() = 0;
};

class Eatable {
public:
    virtual void eat() = 0;
};

class Human : public Workable, public Eatable {
public:
    void work() override { /* 人工作 */ }
    void eat() override { /* 人吃饭 */ }
};

class Robot : public Workable {
public:
    void work() override { /* 机器人工作 */ }
};

改进点：

• 把 Worker 拆分成 Workable 和 Eatable，避免不必要的实现。

---

5. 依赖倒置原则（DIP）

高层模块不应该依赖低层模块，而应该依赖于抽象（接口）。

❌ 违反 DIP 的例子

class LEDLight {
public:
    void turnOn() { /* 打开 LED 灯 */ }
};

class Switch {
private:
    LEDLight light;
public:
    void operate() { light.turnOn(); }
};

问题：

• Switch 直接依赖 LEDLight，如果要支持 白炽灯，必须修改 Switch，违反 OCP 和 DIP。

✅ 遵循 DIP 的改进

class Light {
public:
    virtual void turnOn() = 0;
    virtual ~Light() = default;
};

class LEDLight : public Light {
public:
    void turnOn() override { /* 打开 LED 灯 */ }
};

class IncandescentLight : public Light {
public:
    void turnOn() override { /* 打开白炽灯 */ }
};

class Switch {
private:
    Light& light;
public:
    Switch(Light& l) : light(l) {}
    void operate() { light.turnOn(); }
};

改进点：

• Switch 依赖 Light 接口，不依赖具体的 LEDLight，符合 DIP。
• 以后要支持新灯泡 不修改 Switch 代码。

---

总结

原则	含义	好处
SRP	一个类只做一件事	降低耦合，提高可维护性
OCP	类应对扩展开放，对修改关闭	增加功能时不修改已有代码
LSP	子类可以替换父类，不影响功能	确保继承不会破坏系统
ISP	接口应该小而精，不要强迫实现不需要的功能	降低实现负担，提高灵活性
DIP	依赖接口，不依赖具体实现	提高可扩展性，降低耦合

---

结论

遵循 SOLID 原则可以写出更好的代码，使系统更易扩展、维护和测试。在设计类和模块时，应尽量减少耦合，提高可复用性，避免不必要的修改。