软件设计之 SOLID 原则

Posted on by mindthink
内容目录

solid

目的：合理安排类与函数、类之间的关系，使得软件达到高内聚、低耦合的目标。

  • 单一职责原则（Single Responsibility Principle, SRP）
    一个类应该只有一个引起它变化的原因。这意味着一个类应该只有一个工作或责任。
    例如，一个日志记录器类只负责日志记录，而不负责其他功能，比如数据验证或网络通信。

    class Logger {
public:
void logMessage(const std::string& message) {
    // 记录消息到日志
}
};
  • 开闭原则（Open-Closed Principle, OCP）
    软件实体（比如类、模块、函数等）应该对扩展开放，对修改关闭。这意味着应该能够在不修改现有代码的情况下扩展一个类的行为。
    例如，使用抽象基类定义一个支付处理器接口，然后通过继承来扩展新的支付方法。

    class PaymentProcessor {
public:
virtual void processPayment(double amount) = 0;
};
class WechatPayProcessor : public PaymentProcessor {
public:
void processPayment(double amount) override {
    // 使用微信支付处理
}
};
class AliPayProcessor : public PaymentProcessor {
public:
void processPayment(double amount) override {
    // 使用 支付宝处理
}
};
  • 里氏替换原则（Liskov Substitution Principle, LSP）
    子类应该能够替换它们的基类而不影响程序的正确性。这意味着一个使用基类的程序同样应该能够使用其子类而不需修改。
    例如，如果有一个函数接受基类 PaymentProcessor 作为参数，那么它应该能够同样接受 WechatPayProcessor 或 AliPayProcessor 作为参数，而不影响功能。

    void processTransaction(PaymentProcessor& processor, double amount) {
processor.processPayment(amount);
}
  • 接口隔离原则（Interface Segregation Principle, ISP)
    不应该强迫客户依赖于它们不使用的接口。这意味着应该创建细小的、特定的接口而不是大而全的接口。
    例如，如果有一些支付处理器需要退款功能，而另一些不需要，那么应该将退款功能分离到一个单独的接口中。

    class RefundProcessor {
public:
virtual void processRefund(double amount) = 0;
};
class AdvancedPaymentProcessor : public PaymentProcessor, public RefundProcessor {
// 实现支付和退款功能
};

  • 依赖倒置原则（Dependency Inversion Principle, DIP）
    高层模块不应该依赖于低层模块，两者都应该依赖于抽象；抽象不应该依赖于具体实现，具体实现应该依赖于抽象。这意味着在代码中应该依赖于接口或抽象类，而不是具体的类。
    例如，一个订单处理系统应该依赖于 PaymentProcessor 接口，而不是具体的支付处理实现。

    class OrderSystem {
private:
PaymentProcessor& paymentProcessor;
public:
OrderSystem(PaymentProcessor& processor) : paymentProcessor(processor) {}

void processOrder(double amount) {
    // 使用 paymentProcessor 处理支付
    paymentProcessor.processPayment(amount);
}
};
打赏作者