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

一、单一职责原则（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 {
    @Override
    public void draw() { /*...*/ }
}

class Square implements Shape {
    @Override
    public void draw() { /*...*/ }
}

// 扩展时不修改原有代码
class Triangle implements Shape {
    @Override
    public 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; }
}

总结与原则关联性

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

DIP 与 OCP：依赖倒置是实现开闭原则的基础（通过抽象扩展功能）。
ISP 与 SRP：接口隔离是单一职责在接口设计中的体现。
CRP 与 LSP：组合复用减少继承滥用，间接支持里氏替换。

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