单一职责原则开闭原则其他开发原则

一、单一职责原则（Single Responsibility Principle, SRP）

定义

一个类应该有且仅有一个引起它变化的原因（即一个类只负责一个职责）。

核心思想

• 高内聚：类的功能高度集中

• 低耦合：减少不同职责之间的相互影响

• 提升可维护性：修改一个功能不会波及其他功能

---

违反SRP的示例

// 一个类同时处理订单逻辑和数据库操作
class OrderService {// 职责1：计算订单总价public double calculateTotal(Order order) {// 计算逻辑...}// 职责2：保存到数据库public void saveToDatabase(Order order) {// 数据库操作...}// 职责3：发送邮件通知public void sendEmail(Order order) {// 邮件发送逻辑...}
}

问题：
订单计算、数据库存储、邮件通知这三个职责耦合在一起，任一需求变更都需要修改该类。

---

符合SRP的改进

// 拆分三个独立类
class OrderCalculator {public double calculateTotal(Order order) { /*...*/ }
}class OrderRepository {public void saveToDatabase(Order order) { /*...*/ }
}class EmailService {public void sendEmail(Order order) { /*...*/ }
}// 通过组合方式使用
class OrderService {private OrderCalculator calculator;private OrderRepository repository;private EmailService emailService;public void processOrder(Order order) {double total = calculator.calculateTotal(order);repository.saveToDatabase(order);emailService.sendEmail(order);}
}

优势：

• 每个类职责明确

• 修改邮件发送逻辑不会影响订单计算

• 更易复用（例如EmailService可用于其他模块）

---

二、开闭原则（Open/Closed Principle, OCP）

定义

软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。

核心思想

• 通过抽象和继承/组合实现扩展

• 不修改已有代码即可添加新功能

• 减少回归测试风险

---

违反OCP的示例

class ShapeDrawer {public void draw(String shapeType) {if (shapeType.equals("circle")) {drawCircle();} else if (shapeType.equals("square")) {drawSquare();}// 添加新图形需要修改此方法}private void drawCircle() { /*...*/ }private void drawSquare() { /*...*/ }
}

问题：
每次新增图形类型都需要修改draw()方法，违反开闭原则。

---

符合OCP的改进

// 抽象接口
interface Shape {void draw();
}// 具体实现类
class Circle implements Shape {@Overridepublic void draw() { /*...*/ }
}class Square implements Shape {@Overridepublic void draw() { /*...*/ }
}// 扩展时不修改原有代码
class Triangle implements Shape {@Overridepublic void draw() { /*...*/ }
}class ShapeDrawer {public void draw(Shape shape) {shape.draw(); // 通过多态调用}
}

优势：

• 新增图形类型只需添加新类

• 无需修改ShapeDrawer类

• 客户端代码保持稳定

---

三、装饰者模式中的双原则体现

// 1. Component 接口
interface Beverage {
    double cost();
}

// 2. ConcreteComponent
class BlackCoffee implements Beverage {
    @Override
    public double cost() {
        return 2.0; // 基础咖啡价格
    }
}

// 3. Decorator 抽象类
abstract class BeverageDecorator implements Beverage {
    protected Beverage beverage;
    
    public BeverageDecorator(Beverage beverage) {
        this.beverage = beverage;
    }
}

// 4. ConcreteDecorator 具体装饰者
class Sugar extends BeverageDecorator {
    public Sugar(Beverage beverage) {
        super(beverage);
    }

    @Override
    public double cost() {
        return beverage.cost() + 0.5; // 加糖价格
    }
}

class Milk extends BeverageDecorator {
    public Milk(Beverage beverage) {
        super(beverage);
    }

    @Override
    public double cost() {
        return beverage.cost() + 1.0; // 加奶价格
    }
}

回顾之前的咖啡加料示例：

1. SRP体现

• Sugar装饰器只负责加糖价格计算

• Milk装饰器只负责加奶价格计算

• BlackCoffee只提供基础咖啡功能

2. OCP体现

• 添加新配料（如Chocolate）时：

  class Chocolate extends BeverageDecorator {public Chocolate(Beverage beverage) { super(beverage); }@Override public double cost() { return beverage.cost() + 1.5; }
  }

• 无需修改已有的Beverage、BlackCoffee或其他装饰器类

---

四、实际应用对比

案例：支付系统设计

违反OCP的写法

class PaymentProcessor {public void process(String paymentType) {if (paymentType.equals("alipay")) {// 处理支付宝} else if (paymentType.equals("wechat")) {// 处理微信支付}// 新增支付方式需要修改此处}
}

符合OCP的写法

interface Payment {void process();
}class Alipay implements Payment {@Override public void process() { /*...*/ }
}class WechatPay implements Payment {@Override public void process() { /*...*/ }
}// 新增支付方式
class BitcoinPayment implements Payment {@Override public void process() { /*...*/ }
}class PaymentProcessor {public void process(Payment payment) {payment.process();}
}

---

五、原则关系图

       SRP▲│ 通过拆分单一职责│▼
OCP ◄──┐│ 通过抽象扩展▼系统稳定性

关键点：

• SRP是OCP的基础：只有每个类职责单一，才能保证扩展时不会引发意外副作用

• OCP是SRP的目标：通过合理职责划分实现可扩展性

掌握这两个原则，可以显著提升代码的可维护性和可扩展性。实际开发中建议结合设计模式（如装饰者、策略、工厂模式）来实践这些原则。

其他原则补充

1. 里氏替换原则（Liskov Substitution Principle, LSP）

定义：子类必须能够替换父类，且不影响程序的正确性。
核心：继承关系中子类不应破坏父类的行为逻辑。
示例：

• 违反LSP的场景：若父类 Bird 有 fly() 方法，但子类 Penguin（企鹅）不会飞，强制继承会导致方法异常。

• 符合LSP的改进：拆分接口，区分会飞和不会飞的鸟类。

interface Bird {void eat();
}
interface FlyingBird extends Bird {void fly();
}
class Penguin implements Bird { /* 无需实现fly() */ }
class Swallow implements FlyingBird { /* 实现fly() */ }

---

2. 接口隔离原则（Interface Segregation Principle, ISP）

定义：客户端不应依赖它不需要的接口，避免“胖接口”。
核心：通过拆分接口减少冗余依赖。
示例：

• 违反ISP的场景：Printer 接口包含 print() 和 scan() 方法，但 OnlyPrintPrinter 类不需要扫描功能。

• 符合ISP的改进：拆分为 Printable 和 Scannable 接口。

interface Printable { void print(); }
interface Scannable { void scan(); }
class AllInOnePrinter implements Printable, Scannable { /* 实现全部 */ }
class OnlyPrintPrinter implements Printable { /* 仅打印 */ }

---

3. 依赖倒置原则（Dependency Inversion Principle, DIP）

定义：高层模块不依赖低层模块，二者都依赖抽象；抽象不依赖细节，细节依赖抽象。
核心：通过抽象解耦模块间的直接依赖。
示例：

• 违反DIP的场景：OrderService 直接依赖 MySQLDatabase，难以切换数据库。

• 符合DIP的改进：引入 Database 接口，依赖抽象。

interface Database { void connect(); }
class MySQLDatabase implements Database { /* 实现MySQL连接 */ }
class OrderService {private Database db;public OrderService(Database db) { this.db = db; }
}

---

4. 迪米特法则（Law of Demeter, LoD）/ 最少知识原则

定义：对象应减少对其他对象的直接依赖，仅与“直接朋友”交互。
核心：通过中介者降低耦合。
示例：

• 违反LoD的场景：客户类 Customer 直接调用厨房类 Kitchen 和收银类 Cashier。

• 符合LoD的改进：引入 OrderManager 中介类。

class OrderManager {private Kitchen kitchen;private Cashier cashier;public void processOrder() { /* 协调厨房和收银 */ }
}
class Customer {public void placeOrder(OrderManager manager) { manager.processOrder(); }
}

---

5. 组合复用原则（Composite Reuse Principle, CRP）

定义：优先使用组合（has-a）而非继承（is-a）实现复用。
核心：避免继承带来的类爆炸问题。
示例：

• 继承的缺点：汽车类通过继承处理变速箱类型（自动/手动）会导致类爆炸。

• 组合的改进：将变速箱抽象为独立组件，通过组合集成。

interface Transmission { void shift(); }
class AutomaticTransmission implements Transmission { /* 自动换挡 */ }
class Car {private Transmission transmission;public Car(Transmission t) { this.transmission = t; }
}

---

总结与原则关联性

这些原则相互关联，例如：

1. DIP 与 OCP：依赖倒置是实现开闭原则的基础（通过抽象扩展功能）。

2. ISP 与 SRP：接口隔离是单一职责在接口设计中的体现。

3. CRP 与 LSP：组合复用减少继承滥用，间接支持里氏替换。

通过综合应用这些原则，可以构建高内聚、低耦合的系统，提升代码的可维护性和扩展性。