摘要

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

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 {@Overridepublic void setWidth(int w) {this.width = w;this.height = w; // 强行同步宽高}@Overridepublic 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 {@Autowiredprivate 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. 软件设计是一个逐步优化的过程

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

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

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

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

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

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

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

博文参考

《软件设计模式》