C++中应用SOLID原则的核心是合理划分职责、抽象接口、管理依赖与约束继承。1. SRP要求类只做一件事；2. OCP通过虚函数/策略模式支持扩展不修改；3. LSP强调子类可安全替换父类；4. ISP主张小而专的接口；5. DIP要求高层依赖抽象而非具体实现。
展不修改；3. LSP强调子类可安全替换父类；4. ISP主张小而专的接口；5. DIP要求高层依赖抽象而非具体实现。在C++中应用SOLID原则，核心不是强行套用术语，而是通过合理的类职责划分、接口抽象、依赖管理与继承约束，让代码更易维护、可扩展、可测试。下面结合常见场景，用简洁、真实的C++代码说明每条原则怎么落地。
单一职责原则（SRP）：一个类只做一件事
类的职责越聚焦，修改风险越低。比如“订单处理”和“订单日志记录”应分离，而不是塞进同一个Order类。
// ❌ 违反SRP：Order既处理业务逻辑，又负责写日志
class Order {
public:
void process() { /* ... */ }
void logToDatabase() { /* ... */ } // 职责混杂
};
// ✅ 符合SRP：职责拆分，Order专注业务，Logger专注输出
class Order {
std::string id_;
public:
void process() { / 核心流程，不碰IO / }
};
class OrderLogger {
public:
void log(const Order& order) {
std::cout << "Logging order: " << order.id_ << "\n";
}
};
关键点：当一个类出现“因为XX原因要改”和“因为YY原因要改”时，大概率该拆了。C++里尤其注意避免把文件操作、网络调用、日志、校验全堆在一个类里。
开闭原则（OCP）：对扩展开放，对修改关闭
新增功能不改原有代码，靠派生或组合实现。C++常用虚函数+多态，或策略模式+模板/运行时多态。
// ✅ 支持添加新支付方式，无需动PaymentProcessor原有逻辑
class PaymentStrategy {
public:
virtual ~PaymentStrategy() = default;
virtual void pay(double amount) const = 0;
};
class CreditCardStrategy : public PaymentStrategy {
void pay(double amount) const override {
std::cout << "Charging $" << amount << " to credit card\n";
}
};
class PayPalStrategy : public PaymentStrategy {
void pay(double amount) const override {
std::cout << "Paying $" << amount << " via PayPal\n";
}
};
class PaymentProcessor {
std::uniqueptr strategy ;
public:
void setStrategy(std::uniqueptr s) {
strategy = std::move(s);
}
void execute(double amount) {
if (strategy) strategy->pay(amount);
}
};
注意：别为“可能扩展”提前抽象——先有具体需求再提炼接口。C++中用std::unique_ptr管理策略，避免裸指针和内存泄漏。
Liskov替换原则（LSP）：子类能无缝替代父类
继承不是为了代码复用，而是为了多态替换。子类不能破坏父类契约（比如改写后抛异常、缩小前置条件、扩大后置条件）。
// ❌ 违反LSP：Rectangle和Square语义冲突
class Rectangle {
protected:
double width_, height_;
public:
virtual void setWidth(double w) { width_ = w; }
virtual void setHeight(double h) { height_ = h; }
double area() const { return width_ * height_; }
};
class Square : public Rectangle {
public:
void setWidth(double w) override { width = height = w; }
void setHeight(double h) override { width = height = h; }
// 问题：用户调用setHeight后，width也变了，area行为不可预测
};
// ✅ 更安全做法：不用继承，用组合 + 接口
class Shape {
public:
virtual double area() const = 0;
virtual ~Shape() = default;
};
class Rectangle : public Shape {
double w, h;
public:
Rectangle(double w, double h) : w(w), h(h) {}
double area() const override { return w * h; }
};
class Square : public Shape {
double side;
public:
Square(double s) : side(s) {}
double area() const override { return side * side; }
};
C++中特别注意：不要重写虚函数却改变其异常规范（noexcept）、返回类型（协变除外）、参数语义。用override显式标注，编译器会帮你检查。
接口隔离原则（ISP）：用多个小而专的接口，代替庞大臃肿的接口
客户端不该被迫依赖它不用的接口。C++没有interface关键字，但可用纯虚类模拟；也可用模板约束（requires）配合概念（C++20）。
// ❌ 大而全的接口，PrinterUser必须实现所有，哪怕只打印
class Printer {
public:
virtual void print() = 0;
virtual void scan() = 0;
virtual void fax() = 0;
};
// ✅ 拆成三个独立接口，按需实现
class Printable { public: virtual void print() = 0; };
class Scannable { public: virtual void scan() = 0; };
class Faxable { public: virtual void fax() = 0; };
class SimplePrinter : public Printable {
void print() override { std::cout << "Printing...\n"; }
};
class MultiFunctionDevice : public Printable, public Scannable, public Faxable {
void print() override { / ... / }
void scan() override { / ... / }
void fax() override { / ... / }
};
实际项目中，还可结合PIMPL或桥接模式隐藏实现细节。C++20后，用concept进一步约束模板参数（如requires Printable
依赖倒置原则（DIP）：依赖抽象，不依赖具体实现
高层模块（如业务逻辑）不应依赖低层模块（如数据库、网络），二者都应依赖抽象（接口）。C++中通过构造注入、setter注入或工厂实现。
// ❌ 高层直接new具体类，紧耦合
class UserService {
Database db_; // 直接依赖具体类
public:
bool saveUser(const User& u) { return db_.save(u); }
};
// ✅ 依赖抽象，运行时注入具体实现
class DatabaseInterface {
public:
virtual ~DatabaseInterface() = default;
virtual bool save(const User& u) = 0;
};
class UserService {
std::uniqueptr db ;
public:
explicit UserService(std::uniqueptr db)
: db (std::move(db)) {}
bool saveUser(const User& u) { return db_->save(u); }};
// 使用时才决定具体实现
auto service = UserService{std::make_unique()};
小技巧：C++中优先用值语义或智能指针传入依赖，避免全局单例或静态工厂——它们会让单元测试难以Mock，也隐藏了依赖关系。
基本上就这些。SOLID不是代码教条，而是设计意识。C++里灵活运用虚函数、智能指针、RAII、模板和现代特性（如concept、module），能让SOLID落地得自然不僵硬。不复杂但容易忽略——真正难的，是判断什么时候该抽象、什么时候该保持简单。
