1. SRP:单一职责原则 (Single Responsibility Principle)
原则:一个类应该只有一个引起它变化的原因(即只做一件事)。
[反例] 上帝类 (God Class)
一个 VM 类既负责执行指令,又负责文件 IO,还负责格式化输出日志。
cpp
class VM {
public:
void Run(const char* bytecode); // 核心业务
void LoadFile(const std::string& path); // IO 职责
void LogError(const std::string& msg); // 日志/UI 职责
};
问题:如果我想改日志格式,得改 VM;如果我想改文件读取方式,也得改 VM。VM 类会变得极其臃肿。
[正例] 职责分离
将辅助功能剥离,VM 只关注核心的"执行"。
cpp
// 1. Loader 负责加载
class ProgramLoader {
public:
std::vector<uint8_t> Load(const std::string& path);
};
// 2. Logger 负责日志
class Logger {
public:
void Log(const std::string& msg);
};
// 3. VM 只负责执行
class VM {
public:
void Run(const std::vector<uint8_t>& code);
};
实战思考 :在 cilly-vm-cpp 中,StackStats 就是一个很好的 SRP 实践------它把栈统计逻辑从 VM 中剥离了出来。
2. OCP:开闭原则 (Open/Closed Principle)
原则 :软件实体(类、模块、函数)应该对扩展开放,对修改关闭 。 核心 :加新功能时,最好只加新代码 ,而不是改旧代码。
[反例] Switch 满天飞
在 AST 处理中,使用 enum 和 switch 是最容易违反 OCP 的地方。
cpp
enum class ExprKind { kAdd, kSub };
void Evaluate(Expr* expr) {
switch (expr->kind) {
case kAdd: /* ... */ break;
case kSub: /* ... */ break;
// 每次加新类型 kMul,都要来这里改代码!
}
}
[正例] 访问者模式 (Visitor Pattern)
利用多态和双分派,将操作抽象为 Visitor。
cpp
// 1. 定义访问者接口
class ExprVisitor {
public:
virtual void Visit(class AddExpr* expr) = 0;
virtual void Visit(class SubExpr* expr) = 0;
};
// 2. 元素基类接受访问者
struct Expr {
virtual void Accept(ExprVisitor& v) = 0;
};
// 3. 具体元素实现 Accept
struct AddExpr : Expr {
void Accept(ExprVisitor& v) override { v.Visit(this); }
};
// 4. 扩展功能:只需新增 Visitor,无需改动 Expr 类
class Printer : public ExprVisitor {
void Visit(AddExpr* expr) override { std::cout << "+"; }
void Visit(SubExpr* expr) override { std::cout << "-"; }
};
3. LSP:里氏替换原则 (Liskov Substitution Principle)
原则 :子类对象必须能够替换掉所有父类对象,而不会导致程序错误。 通俗理解 :父类能用的地方,换成子类也能用,且不会炸。
[反例] 正方形不是长方形
cpp
class Rectangle {
public:
virtual void SetWidth(int w) { width_ = w; }
virtual void SetHeight(int h) { height_ = h; }
int Area() const { return width_ * height_; }
protected:
int 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(5);
r.SetHeight(4);
assert(r.Area() == 20); // 传入 Square 时,这里会断言失败(结果是 16)
}
[正例] GC 对象契约
在 GC 系统中,所有对象都继承自 GcObject。
cpp
class GcObject {
public:
// 契约:子类必须在这个函数里报告它引用的所有子对象
virtual void Trace(Collector& c) = 0;
};
// 只要 StringObject 正确实现了 Trace(哪怕它是空的),
// 它就能被 Collector 正确处理,不会导致 GC 崩溃。
class StringObject : public GcObject {
void Trace(Collector& c) override { /* 无引用,空实现即可 */ }
};
4. ISP:接口隔离原则 (Interface Segregation Principle)
原则 :客户端不应该依赖它不需要的接口。 核心 :接口要小而专,避免大而全。
[反例] 胖接口
cpp
class ISmartObject {
public:
virtual void Serialize() = 0; // 序列化
virtual void Trace() = 0; // GC 标记
virtual void Draw() = 0; // UI 绘制
};
// 仅仅是一个简单的数据对象,却被迫实现 Draw()
class DataNode : public ISmartObject {
void Serialize() override { ... }
void Trace() override { ... }
void Draw() override { /* 抛异常或空实现 */ } // 违反 ISP
};
[正例] 接口拆分
cpp
class ISerializable { virtual void Serialize() = 0; };
class IGcTraceable { virtual void Trace() = 0; };
class IDrawable { virtual void Draw() = 0; };
// 按需组合
class DataNode : public ISerializable, public IGcTraceable { ... };
class UiNode : public IDrawable, public IGcTraceable { ... };
5. DIP:依赖倒置原则 (Dependency Inversion Principle)
原则 :高层模块不应该依赖低层模块,二者都应该依赖其抽象。 核心 :面向接口编程。
[反例] 依赖具体实现
VM 直接依赖具体的标记清除 GC (MarkSweepCollector)。
cpp
class MarkSweepCollector { ... };
class VM {
MarkSweepCollector gc_; // 强耦合!
public:
VM() { ... }
};
如果我想换成引用计数 GC (RefCountCollector),必须修改 VM 类的定义。
[正例] 依赖抽象接口
cpp
// 1. 定义抽象接口
class IGcCollector {
public:
virtual void Collect() = 0;
virtual ~IGcCollector() = default;
};
// 2. VM 依赖接口
class VM {
IGcCollector* gc_;
public:
// 3. 通过构造函数注入具体实现
VM(IGcCollector* gc) : gc_(gc) {}
};
// 4. 外部决定用哪种 GC
int main() {
MarkSweepCollector my_gc;
VM vm(&my_gc);
// 或者 VM vm(new CopyingCollector());
}
总结
- SRP: 一个类只做一件事。
- OCP: 多态是关键,加新功能不改旧代码。
- LSP: 子类必须能完全替代父类(行为不缩水、不捣乱)。
- ISP: 接口要小,不要强迫子类实现没用的方法。
- DIP: 依赖抽象接口,方便替换底层实现。