设计模式的设计原则

设计模式之所以能解决软件开发中的复杂问题，是因为它们背后遵循了一套核心的面向对象设计原则。这些原则通常被总结为 SOLID 原则，加上其他几个经典原则，构成了软件设计的基石。

以下是设计模式背后的核心设计原则详解：

---

一、 SOLID 原则（核心五大原则）

这是由 Robert C. Martin (Uncle Bob) 总结的面向对象编程的五大基本原则：

1. 单一职责原则 (SRP - Single Responsibility Principle)

定义：一个类应该只有一个引起它变化的原因。

• 核心思想：高内聚。一个类只负责一项职责（或一个业务领域）。
• 好处：降低类的复杂度，提高可读性；修改某个功能时不会影响其他功能。
• 反例：一个 User 类既负责从数据库读取数据，又负责生成 HTML 报表。

2. 开闭原则 (OCP - Open/Closed Principle)

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

• 核心思想：当需求变化时，通过增加新代码来扩展行为，而不是修改现有代码。
• 实现手段：多态、抽象、接口。
• 典型模式：策略模式、装饰器模式、观察者模式。

3. 里氏替换原则 (LSP - Liskov Substitution Principle)

定义：子类对象必须能够替换掉所有父类对象，而程序行为不变。

• 核心思想：继承必须确保父类所拥有的性质在子类中仍然成立。不要破坏继承体系的契约。
• 反例：正方形继承长方形。如果 setHeight() 同时改变了 width，那么在使用长方形的地方换成正方形就会出错。

4. 接口隔离原则 (ISP - Interface Segregation Principle)

定义：客户端不应该依赖它不需要的接口。

• 核心思想：使用多个专门的接口，而不是一个庞大的总接口。保持接口的纯粹和细粒度。
• 好处：避免“胖接口”，减少类之间的耦合。

5. 依赖倒置原则 (DIP - Dependency Inversion Principle)

定义：

1. 高层模块不应该依赖低层模块，两者都应该依赖抽象。
2. 抽象不应该依赖细节，细节应该依赖抽象。

• 核心思想：面向接口编程，而不是面向实现编程。
• 典型模式：依赖注入 (DI)、控制反转 (IoC)。

---

二、 其他重要设计原则

除了 SOLID，以下原则在实际工程中同样至关重要：

6. 迪米特法则 (LoD - Law of Demeter / 最少知识原则)

定义：一个对象应该对其他对象有最少的了解。只与直接的朋友通信。

• 核心思想：降低耦合度。不要调用 a.getB().getC().doSomething() 这种深层链式调用。
• 好处：系统模块之间保持松散耦合，修改一个模块不会波及太远。

7. 合成复用原则 (CRP - Composite Reuse Principle)

定义：尽量使用对象组合/聚合，而不是继承来达到复用的目的。

• 核心思想：组合优于继承。
• 原因：继承是白盒复用（破坏了封装性，父类改动影响所有子类）；组合是黑盒复用（通过接口交互，灵活且安全）。
• 典型模式：装饰器模式、桥接模式、代理模式。

8. 共同封闭原则 (CCP - Common Closure Principle)

定义：把会一起修改的类放在同一个包/模块中。

• 核心思想：这是 SRP 在架构/包级别的应用。相关的代码应该聚在一起。

9. 稳定抽象原则 (SAP - Stable Abstractions Principle)

定义：一个包的抽象程度应该与其稳定程度一致。

• 核心思想：稳定的包应该是抽象的（如接口层），不稳定的包应该是具体的（如实现层）。这保证了架构的灵活性。

---

三、 总结：原则与设计模式的关系

表格

 

设计原则	解决的核心问题	对应的常见设计模式
单一职责 (SRP)	类太臃肿，难以维护	门面模式、代理模式
开闭原则 (OCP)	需求变更导致代码大面积修改	策略模式、模板方法、观察者模式
里氏替换 (LSP)	继承滥用导致逻辑错误	契约式设计、断言
接口隔离 (ISP)	接口过大，强迫实现无用方法	适配器模式、外观模式
依赖倒置 (DIP)	高层业务与底层技术强耦合	工厂模式、依赖注入
迪米特法则 (LoD)	对象间依赖链条过长	中介者模式、门面模式
合成复用 (CRP)	继承树过深，牵一发而动全身	装饰器模式、桥接模式、组合模式

给开发者的建议

1. 原则是指南针，不是法律：不要为了遵守原则而过度设计。如果业务逻辑极其简单且未来几乎不会变，一个简单的 if-else 可能比一套策略模式+工厂模式更好。
2. 重构是必经之路：很难在第一遍写代码时就完美符合所有原则。先让代码跑起来，再根据原则进行重构。
3. 识别“坏味道”：当你发现一个类改了 A 功能，B 功能也坏了（违反 SRP）；或者加一个新类型要改 10 个文件（违反 OCP），这就是应用设计模式和原则的最佳时机。

掌握这些原则，你就掌握了判断代码好坏的标准，而设计模式只是你在标准下解决问题的具体工具箱