在软件工程中，SOLID原则就像是建筑工程中的力学规范。它们不是硬性的语法规定，而是为了解决软件开发中最为头疼的问题：代码的腐化（Code Rot）。当你的代码变得难以维护、改一处坏十处、或者无法测试时，通常是因为违背了这些原则。
下面我们就逐一拆解这五个核心原则。
- 单一职责原则和接口隔离原则：如何划分模块和接口，即保持简单精细
- 里式替换原则和依赖倒置原则：设计类与类之间的关系，面向抽象和多态
- 开闭原则：最终的设计目标，易于拓展、拒绝修改的软件架构
S - 单一职责原则 (SRP)
- 出发点：一个类应该只有一个引起它变化的原因。
- 解决问题：高耦合。如果一个类承担了太多的功能（比如既处理数据逻辑，又处理文件保存），那么当保存格式变化时，可能会无意中破坏数据逻辑的代码。
- 核心痛点：如果你在
Employee 类里既写薪水计算，又写 HTML 报表生成，那么当财务规则改变或 UI 风格改变时，你都得去改同一个文件，这会大大增加回归测试的压力。
个人理解：SRP 告诉我们如果类写得太大的话，我们应该如何拆分这个类 / 函数。与之相关的一个实践是，函数最好能够被一个屏幕放下。
修改前：全能类
1
2
3
4
5
6
7
| class Employee {
public:
double calculatePay() { return 4000.0; }
void saveToDatabase() { }
string generateReport() { return "<html>Employee Report</html>"; }
};
|
修改后：职责分离
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| class Employee {
public:
double calculatePay() { return 4000.0; }
};
class EmployeeRepository {
public:
void save(const Employee& e) { }
};
class EmployeeReporter {
public:
string generateHTML(const Employee& e) { return "<html>...</html>"; }
};
|
O - 开闭原则 (OCP)
- 出发点：软件实体（类、模块、函数）应对扩展开放，对修改关闭。
- 解决问题：脆弱性。如果每次增加新功能都要改动现有的核心代码，极易引入 Bug。
- 核心痛点：如果不使用 OCP，每增加一个新功能（如新的支付方式），你都得在
switch-case 块里加一行，这违反了“对修改关闭”的原则，容易改坏老代码。
「对拓展开放，对修改关闭」：
- 如果出现多个不同执行流的
if / switch ，可以拆分为接口，让上层构造对应的对象并调用该接口
- 虚函数或者接口就是一种对拓展开放的方式，子类可以选择所需的接口进行实现
修改前：依赖硬编码判断
1
2
3
4
5
6
7
8
9
| class Logger {
public:
void log(string msg, string type) {
if (type == "File") { }
else if (type == "Console") { }
}
};
|
修改后：通过继承扩展
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| class ILogger {
public:
virtual ~ILogger() = default;
virtual void log(const string& msg) = 0;
};
class FileLogger : public ILogger {
void log(const string& msg) override { }
};
class ConsoleLogger : public ILogger {
void log(const string& msg) override { }
};
|
L - 里氏替换原则 (LSP)
- 出发点：子类对象必须能够替换掉所有的父类对象，且程序的行为不发生变化。
- 解决问题：错误的继承体系。它强制要求派生类必须完全兼容基类的承诺，避免在多态调用时产生意外。
- 核心痛点：子类如果改变了父类预期的行为（例如父类说能写，子类却抛出“只读”异常），那么调用者在使用多态时就会崩溃。
修改前：破坏契约
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| class Rectangle {
protected:
int width, height;
public:
virtual void setWidth(int w) { width = w; }
virtual void setHeight(int h) { height = h; }
int getArea() { return width * height; }
};
class Square : public Rectangle {
public:
void setWidth(int w) override { width = height = w; }
void setHeight(int h) override { width = height = h; }
};
void resize(Rectangle& r) {
r.setWidth(10);
r.setHeight(5);
}
|
修改后：重新抽象
1
2
3
4
5
6
| class Shape {
public:
virtual int getArea() const = 0;
};
|
I - 接口隔离原则 (ISP)
- 出发点：不应该强迫客户端依赖它不需要的方法。
- 解决问题：臃肿的接口。大而全的接口会导致实现类被迫实现无意义的空函数，增加系统的复杂度和耦合。
- 核心痛点：如果接口太“胖”，实现类就必须写一堆
// do nothing 的空函数，这不仅浪费代码，也误导了接口的使用者。
修改前：臃肿接口
1
2
3
4
5
6
7
8
9
10
11
12
13
| class IMultiFunctionDevice {
public:
virtual void print() = 0;
virtual void scan() = 0;
virtual void fax() = 0;
};
class OldPrinter : public IMultiFunctionDevice {
void print() override { }
void scan() override { }
void fax() override { }
};
|
修改后：精简接口
1
2
3
4
5
6
7
| class IPrinter { virtual void print() = 0; };
class IScanner { virtual void scan() = 0; };
class OldPrinter : public IPrinter {
void print() override { }
};
|
D - 依赖倒置原则 (DIP)
- 出发点：高层模块不应依赖低层模块，两者都应依赖其抽象。
- 解决问题：僵化性。传统做法是高层直接调用底层，导致底层一旦变动（比如换了个数据库），高层必须重写。
- 核心痛点：高层业务逻辑如果直接依赖底层的具体库（如特定品牌的数据库驱动），那么底层一换，高层全挂。
修改前：高层依赖底层
1
2
3
4
5
6
7
8
9
10
11
| class LowLevelSqlite {
public:
void execute(string sql) { }
};
class HighLevelService {
LowLevelSqlite* db;
public:
void run() { db->execute("SELECT..."); }
};
|
修改后：两者依赖抽象
1
2
3
4
5
6
7
8
9
10
11
12
| class IDatabase {
public:
virtual void execute(string sql) = 0;
};
class HighLevelService {
IDatabase& db;
public:
HighLevelService(IDatabase& d) : db(d) {}
void run() { db.execute("SELECT..."); }
};
|
总结：SOLID 如何让代码更健壮？
这五个原则并不是独立的，它们共同构建了一个解耦的防御体系：
- 健壮性（Robustness）：通过 SRP 和 LSP，我们将错误限制在最小的模块内。当一个功能出错时，不会因为复杂的耦合导致连环崩塌；同时，子类的替换安全性保证了多态调用的可靠。
- 可扩展性（Extensibility）：OCP 和 DIP 是扩展的基石。当你需要新功能时，你是在“写新代码”而不是“改老代码”。通过依赖抽象，你可以像插拔 USB 设备一样灵活地更换系统底层的组件。
- 可维护性（Maintainability）：ISP 保证了接口的简洁，让开发者一眼就能明白某个模块能做什么，而不必在一堆无用的空函数中寻找逻辑。
简单来说：SOLID 原则把一块巨大的、硬邦邦的“大理石代码”变成了可以灵活组装的“乐高积木”。
