设计模式——面向对象设计六大原则

摘要

本文详细介绍了设计模式中的六大基本原则，包括单一职责原则、开放封闭原则、里氏替换原则、接口隔离原则、依赖倒置原则和合成复用原则。每个原则都通过定义、理解、示例三个部分进行阐述，旨在帮助开发者提高代码的可维护性和灵活性。通过具体代码示例，文章展示了如何在实际项目中应用这些原则，以优化软件设计。

1. 单一职责原则

1.1. ✅ 定义：

一个类只负责一件事 ，有且仅有一个引起它变化的原因。

1.2. ✅ 理解：

这是单一职责原则（SRP）背后的核心动机：变化的原因越多，类的稳定性就越差，维护成本也就越高。如果一个类承担了太多职责，当其中一个职责变化时，可能会影响其他功能。

1.3. ✅ 示例

1.3.1. 职责=变化的原因

一个"职责"，本质上代表的是一个变化的原因。如果一个类承担了多种职责，它就会被多种不同的变化触发修改。

举例说明：

复制代码

class ReportService {
    public void generateReport() {
        // 业务逻辑
    }

    public void saveToFile(String content) {
        // IO 文件保存逻辑
    }

    public void sendEmail(String content) {
        // 邮件发送逻辑
    }
}

这个类承担了 三种职责：

报表生成（业务变化时要改）
文件保存（存储方式变化时要改）
邮件发送（邮件策略变化时要改）

1.3.2. 职责之间强耦合，牵一发动全身

如果某天要变更邮件发送策略（如改用 Kafka 异步通知），你可能会：

改 sendEmail 方法；
但如果修改失误或测试不足，可能会影响 generateReport 或 saveToFile 方法的逻辑。

这就带来了：

不必要的风险（改一处，误伤其他）；
不利于复用（不能只复用报表逻辑而不带邮件逻辑）；
影响可测试性（一个测试类测试了多个功能）。

1.3.3. 职责分离后好处：解耦 + 高内聚

将不同职责分离成不同类：

复制代码

class ReportGenerator {
    public String generateReport() { ... }
}

class FileStorage {
    public void saveToFile(String content) { ... }
}

class EmailNotifier {
    public void sendEmail(String content) { ... }
}

好处：

每个类只受一种变化影响；
修改一个模块不会误伤其他；
更容易测试、复用和维护；
符合高内聚、低耦合的设计理念。

2. 开放封闭原则（OCP：Open Closed Principle）

2.1. ✅ 定义：

对扩展开放 ，对修改封闭 ------允许对类行为的扩展，但不允许修改原有代码。

2.2. ✅ 理解：

通过接口、抽象类和多态机制，新增功能时不动旧代码，提升系统稳定性。也就是说，系统应该允许在不修改已有代码的前提下添加新功能，以提升稳定性、可维护性和可扩展性。通过抽象（接口/抽象类）定义稳定的扩展点，新功能只需新增实现类，通过多态机制 接入，无需改动原有逻辑。抽象（接口/抽象类）+ 多态 = 构建扩展点，新增不改旧，系统更稳定。这是一种高质量、可持续演进的系统设计策略。

2.3. ✅ 示例：

假设你正在开发一个支付系统 ，最开始只支持微信支付：

复制代码

// 早期版本
public class PaymentService {
    public void pay(String type) {
        if ("wechat".equals(type)) {
            System.out.println("微信支付");
        }
    }
}

缺点：

每增加一个支付方式（如支付宝、银行卡等），就要改动 pay 方法；
增加逻辑风险，测试成本提高，稳定性下降。

2.3.1. 面向抽象编程（重构）

复制代码

// 抽象接口
public interface PayStrategy {
    void pay();
}

// 微信支付实现
public class WeChatPay implements PayStrategy {
    public void pay() {
        System.out.println("微信支付");
    }
}

// 支付宝支付实现
public class AlipayPay implements PayStrategy {
    public void pay() {
        System.out.println("支付宝支付");
    }
}

// 上层调用
public class PaymentService {
    private PayStrategy payStrategy;

    public PaymentService(PayStrategy payStrategy) {
        this.payStrategy = payStrategy;
    }

    public void execute() {
        payStrategy.pay();
    }
}

2.3.2. 重构后好处：

新增支付方式，只需实现新的 PayStrategy 子类；
PaymentService 不需要改动，遵循 开放-封闭原则；
利用了接口+多态，实现功能扩展与旧代码解耦。

2.3.3. 应用场景

|--------|--------------------|--------------------------|--------------------|
| 场景 | 抽象化方式 | 多态实现 | 示例说明 |
| 日志记录 | Logger 接口 | FileLogger, DBLogger | 新增日志方式无需修改旧逻辑 |
| 排序策略 | Comparator<T> 接口 | 自定义 compare方法 | 支持多种排序方式 |
| 消息推送 | PushService 接口 | EmailPush, SmsPush | 扩展渠道不影响已有逻辑 |
| 业务规则引擎 | Rule 抽象类或接口 | 各种规则类 | 增加规则时只需新增类，不动主流程代码 |

3. 里氏替换原则（LSP：Liskov Substitution Principle）

3.1. ✅ 定义：

子类必须能够替换父类，程序逻辑的正确性不被破坏。

3.2. ✅ 理解：

子类继承父类时，不应改变父类原有功能的语义，否则违背了替换原则。子类在继承父类时，不能违背父类原有的语义和行为约定 ，否则就破坏了继承的正确性。如果一个子类违背了父类的行为预期，那么它就不能被替换为父类使用，会导致系统运行异常或逻辑错误。

3.3. ✅ 示例：

3.3.1. 不符合 LSP 的示例（反例）

场景：设计一个"矩形"和"正方形"的类。

复制代码

class Rectangle {
    protected int width;
    protected int height;

    public void setWidth(int w) { this.width = w; }
    public void setHeight(int h) { this.height = h; }

    public int getArea() {
        return width * height;
    }
}

正方形继承矩形：

复制代码

class Square extends Rectangle {
    
    @Override
    public void setWidth(int w) {
        this.width = w;
        this.height = w; // 强行同步宽高
    }

    @Override
    public void setHeight(int h) {
        this.height = h;
        this.width = h; // 强行同步宽高
    }
}

问题点：

复制代码

Rectangle r = new Square();
r.setWidth(4);
r.setHeight(5);
System.out.println(r.getArea());  // 原预期是 4 * 5 = 20，但实际输出 25！

你以为你用的是 Rectangle ，但行为却是 Square 强行同步宽高 ，导致语义变化，替换失败，这就违反了 LSP。

3.3.2. 符合 LSP 的示例（正例）

解决方式是：将 Rectangle 和 Square 分开设计，不要使用继承，而是将"正方形"作为特殊矩形逻辑的聚合或组合。

复制代码

interface Shape {
    int getArea();
}

class Rectangle implements Shape {
    protected int width;
    protected int height;

    public Rectangle(int w, int h) {
        this.width = w;
        this.height = h;
    }

    public int getArea() {
        return width * height;
    }
}

class Square implements Shape {
    private int side;

    public Square(int side) {
        this.side = side;
    }

    public int getArea() {
        return side * side;
    }
}

这样你就不会被继承关系"误导"。总结一句话：**不要为了代码复用而继承，如果子类不能完美遵守父类的行为契约，就不应该继承它。**符合里氏替换原则能带来：继承结构的健壮性；多态替换的可靠性；系统运行的一致性。

4. 接口隔离原则（ISP：Interface Segregation Principle）

4.1. ✅ 定义：

不应该强迫客户端依赖它不需要的接口；一个接口最好只包含客户端所需的方法。

4.2. ✅ 理解：

一个接口最好不要太"大" ------ 拆分成小而精的多个接口，避免"胖接口"。

"胖接口"是指一个接口中定义了过多的方法，导致：

实现类必须实现一些无关方法；
实现代码中出现大量的空方法、无意义实现；
模块间耦合度增加，影响代码可维护性、扩展性。

4.3. ✅ 示例：

4.3.1. ❌ 反例：一个"胖接口"

复制代码

public interface Animal {
    void eat();
    void fly();
    void swim();
    void run();
}

如果我们要实现一个 Dog：

复制代码

public class Dog implements Animal {
    public void eat() { System.out.println("吃"); }
    public void fly() { } // 狗不会飞
    public void swim() { System.out.println("狗刨"); }
    public void run() { System.out.println("跑"); }
}

这就是接口污染：被迫实现不需要的 fly() 方法，不符合 ISP。

4.3.2. ✅ 正例：拆分为多个小接口

复制代码

public interface Eater {
    void eat();
}

public interface Flyer {
    void fly();
}

public interface Swimmer {
    void swim();
}

public interface Runner {
    void run();
}

实现类只依赖自己关心的接口：

复制代码

public class Dog implements Eater, Swimmer, Runner {
    public void eat() { System.out.println("吃"); }
    public void swim() { System.out.println("狗刨"); }
    public void run() { System.out.println("跑"); }
}

这样：

每个接口职责单一；
实现类更清晰；
系统更易扩展、测试、维护。

4.3.3. ✅ 现实应用场景举例

|------------------------|---------------------------------------|----------------------------------------------------|
| 场景 | 粗接口（不推荐） | 拆分小接口（推荐） |
| 文件操作工具类 | FileHandler有 read、write、delete、copy | ReadableFile, WritableFile, DeletableFile |
| 用户权限管理接口 | UserService 同时包含注册、登录、授权、查询 | RegisterService, LoginService, AuthService |
| Spring Data Repository | 如果某个 DAO 接口包含不常用的高级查询方法 | 使用继承自 JpaRepository、PagingAndSortingRepository |

5. 依赖倒置原则（DIP：Dependency Inversion Principle）

5.1. ✅ 定义：

高层模块不应该依赖低层模块，二者都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象。

5.2. ✅ 理解：

依赖"抽象"（接口或抽象类），不要直接依赖具体实现类，利于扩展与测试。

程序中模块之间通过"抽象"来交互；
不要在高层业务代码中直接依赖具体实现类；
通过接口/抽象类定义行为，由具体类实现。

为什么需要依赖倒置？

增强可扩展性：替换或扩展底层实现时，不需要修改上层代码；
便于测试：接口更容易被 mock，实现单元测试；
解耦：高层和低层只通过抽象耦合。

5.3. ✅ 示例：

5.3.1. ❌ 反例：高层直接依赖低层实现

复制代码

class MySQLUserDao {
    public void save(String name) {
        System.out.println("保存用户到MySQL：" + name);
    }
}

class UserService {
    private MySQLUserDao dao = new MySQLUserDao(); // 直接依赖实现类

    public void createUser(String name) {
        dao.save(name);
    }
}

UserService 只能使用 MySQLUserDao；
无法替换成其他数据源（如 Redis、Mongo）；
单元测试困难。

5.3.2. ✅ 正例：依赖接口

复制代码

// 抽象
public interface UserDao {
    void save(String name);
}

// 实现
public class MySQLUserDao implements UserDao {
    public void save(String name) {
        System.out.println("保存用户到MySQL：" + name);
    }
}

// 高层只依赖接口
public class UserService {
    
    private final UserDao dao;

    public UserService(UserDao dao) {
        this.dao = dao;
    }

    public void createUser(String name) {
        dao.save(name);
    }
}

这样 UserService 就与实现无关了，你可以注入任何实现：

复制代码

new UserService(new MySQLUserDao());
new UserService(new MockUserDao());

5.3.3. ✅ Spring 中的依赖倒置实践

Spring 框架本身就是依赖倒置原则的典范：

通过@Autowired、构造器注入等，注入接口而非实现；
利用 IOC 容器控制实现类选择；
通过配置文件/注解进行行为替换，无需改动业务代码。

@Service
public class UserService {
复制代码
```
  @Autowired
  private final UserRepository userRepository;
```
}

6. 合成复用原则（CARP：Composition Over Inheritance）

6.1. ✅ 定义：

优先使用"组合"或"聚合"来复用代码，而不是继承。

6.2. ✅ 理解：

继承是强耦合，组合更加灵活，符合"变化点隔离"的设计思想。

|--------|----------------------------------|
| 机制 | 特点简述 |
| 继承 | 是"is-a"关系，子类拥有父类所有行为，强耦合，不灵活 |
| 组合 | 是"has-a"关系，通过属性组合对象，松耦合，更灵活 |
| 聚合 | 是"has-a"的一种特殊情况，组合关系中对象生命周期独立 |

6.3. ✅ 示例：

6.3.1. ❌ 继承的问题

子类会继承父类的所有方法，哪怕有些不需要；
一旦父类修改，所有子类可能都会受影响；
Java 不支持多继承，扩展受限；
难以满足未来需求的变化。

例：

复制代码

class Animal {
    void walk() { System.out.println("动物走"); }
}

class Bird extends Animal {
    void fly() { System.out.println("鸟飞"); }
}

现在你想做一个企鹅（企鹅不会飞），怎么办？继承 Bird 显然不合适，但重新写又代码重复。

6.3.2. ✅ 组合的优点

可以灵活地引入所需能力；
符合变化点隔离原则，不同功能独立演化；
可以更好地应对业务场景变化。

6.3.3. ✅ 示例：用组合代替继承

1. 把行为抽象成接口

复制代码

interface Flyable {
    void fly();
}

interface Walkable {
    void walk();
}

2. 抽离行为实现类

复制代码

class NormalWalk implements Walkable {
    public void walk() { System.out.println("用两条腿走"); }
}

class NoFly implements Flyable {
    public void fly() { System.out.println("我不会飞"); }
}

3. 组合行为到企鹅类中

复制代码

class Penguin {
    
    private Walkable walkBehavior;
    
    private Flyable flyBehavior;

    public Penguin(Walkable walk, Flyable fly) {
        this.walkBehavior = walk;
        this.flyBehavior = fly;
    }

    public void walk() {
        walkBehavior.walk();
    }

    public void fly() {
        flyBehavior.fly();
    }
}

4. 使用

复制代码

Penguin penguin = new Penguin(new NormalWalk(), new NoFly());
penguin.walk(); // 用两条腿走
penguin.fly();  // 我不会飞

6.3.4. 🔧 总结对比

|-------|---------------|-------------|
| 对比点 | 继承 | 组合 |
| 耦合度 | 高（父类变，子类易受影响） | 低（只依赖接口/对象） |
| 灵活性 | 不支持多继承 | 可以组合多个不同功能 |
| 可测试性 | 不易 mock | 易于注入和 mock |
| 改动影响面 | 广 | 局部可控 |
| 设计哲学 | 强制共享行为 | 按需装配功能 |

7. 项目实践怎么遵循设计原则

7.1. 软件设计是一个逐步优化的过程

从上面六个原则的讲解中，应该体会到软件的设计是一个循序渐进，逐步优化的过程。经过一次次的逻辑分析，一层层的结构调整和优化，最终得出一个较为合理的设计图。整个动物世界的类图如下：

我们对上面五个原则做一个总结：

单一职责原则告诉我们实现类要职责单一。用于类的设计，增加一个类时使用 SRP 原则来核对该类的设计是否纯粹干净，也就是让一个类的功能尽可能单一，不要想着一个类包揽所有功能。
里氏替换原则告诉我们不要破坏继承体系。用于指导类继承的设计，设计类之间的继承关系时，使用 LSP 原则来判断这种继承关系是否合理。只要父类能出现的地方子类就能出现（就可以用子类来替换他），反之则不一定成立。
依赖倒置原则告诉我们要面向接口编程。用于指导如何抽象，即要依赖抽象和接口编程，不要依赖具体的实现。
接口隔离原则告诉我们在设计接口的时候要精简单一。用于指导接口的设计，当发现一个接口过于臃肿时，就要对这个接口进行适当的拆分。
开放封闭原则告诉我们要对扩展开放，对修改关闭。开闭原则可以说是整个设计的最终目标和原则！开闭原则是总纲，其他4个原则是对这个原则具体解释。

设计原则是进行软件设计的核心思想和规范。那在实际的项目开发中，是否一定要遵循原则？答案不总是肯定，要视情况而定。因为在实际的项目开发中，必须要安时按量地完成任务。项目的进度受时间成本，测试资源的影响，而且程序一定要保存稳定可以。

还记得我们在单一职责原则中提到一个例子吗？面对需求的变更，我们有三种解决方式：

方法一：直接改原有的函数（方法），这种方式最快速，但后期维护最困难，而且不便拓展；这种方式一定是要杜绝的。
方法二：增加一个新方法，不修改原有的方法，这在方法级别是符合单一职责原则的；但对上层的调用会增加不少麻烦。在项目比较复杂，类比较庞大，而且测试资源比较紧缺的时候，不失为一种快速和稳妥的方式。因为如果要进行大范围的代码重构，势必要对影响到的模块进行全覆盖的测试回归，才能确保系统的稳定可靠。
方法三：增加一个新的类来负责新的职责，两个职责分离，这是符合单一职责原则的。在项目首次开发，或逻辑相对简单的情况下，需要采用这种方式。

在实际的项目开发中，我们要尽可能地遵循这些设计原则。但并不是要 100% 地遵从，需要结果实际的时间成本、测试资源、代码改动难度等情况进行综合评估，适当取舍，采用最高效合理的方式。

博文参考

《软件设计模式》