https://www.leanku.com/categories/designpattern/Recent content in DesignPattern on Leanku 的博客Hugozh-cnMon, 13 Oct 2025 21:46:01 +0800https://www.leanku.com/post/designpattern/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%E5%8E%9F%E5%88%99/Mon, 13 Oct 2025 21:46:01 +0800https://www.leanku.com/post/designpattern/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%E5%8E%9F%E5%88%99/<h1 id="设计模式原则">设计模式原则</h1> <p>设计模式的原则是理解和使用设计模式的基石。这些原则是面向对象设计的核心指导思想，设计模式本身就是这些原则在特定场景下的具体体现。</p> <p>最重要的设计原则是 SOLID 原则，此外还有一些其他关键原则。</p> <h2 id="一-solid-原则">一、 SOLID 原则</h2> <p>SOLID 原则是五个最常用、最经典的设计原则，由 Robert C. Martin 提出。</p> <h3 id="1-单一职责原则">1. 单一职责原则</h3> <ul> <li><strong>核心思想</strong>： 一个类应该只有一个引起变化的原因。</li> <li><strong>详细解释</strong>：一个类只负责一项职责或功能。如果一個类承担的功能过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。</li> <li><strong>比喻</strong>： 一家餐厅，厨师负责做饭，服务员负责点菜和上菜，清洁工负责打扫。如果他们职责混杂，效率就会低下。</li> <li><strong>违反示例</strong>： 一个 UserService 类，既负责用户信息的增删改查，又负责将用户数据导出为PDF报表，还负责发送邮件通知。</li> <li><strong>修正</strong>： 将 UserService 拆分为 UserService（用户业务逻辑）、UserReportGenerator（报表生成）和 EmailService（邮件服务）。</li> </ul> <h3 id="2-开闭原则">2. 开闭原则</h3> <ul> <li>核心思想： 软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。</li> <li>详细解释： 当需求发生变化时，我们应该通过添加新的代码来扩展功能，而不是修改已有的、已经工作正常的代码。这是最重要的原则，是很多设计模式的目标。</li> <li>比喻： 一台电脑，你可以扩展USB设备（鼠标、键盘、硬盘），而无需为了支持新设备而拆开主机修改主板。</li> <li>违反示例： 一个 AreaCalculator 类，有一个 calculate 方法，里面用 if-else 来判断是圆形还是矩形来计算面积。如果要增加三角形，就必须修改这个类的代码。</li> <li>修正： 定义一个 Shape 接口，包含 calculateArea 方法。让 Circle 和 Rectangle 类实现这个接口。AreaCalculator 只需遍历 Shape 列表调用其方法即可。要新增三角形，只需创建 Triangle 类实现 Shape，无需修改任何现有类。</li> </ul> <h3 id="3-里氏替换原则">3. 里氏替换原则</h3> <ul> <li>核心思想： 所有引用基类的地方必须能透明地使用其子类的对象。</li> <li>详细解释： 子类必须能够完全替代它们的父类，而不产生任何错误或意外的行为。也就是说，子类只能在保持原有行为的基础上进行扩展，而不能覆盖或改变父类的核心行为。</li> <li>比喻： 你父亲会开车，你作为儿子继承了他，你也会开车（保持了父亲的行为），但你可能会开得更快或者还会修车（扩展），你绝不能把“开车”这个行为重定义为“游泳”。</li> <li>违反示例： Rectangle 类有 setWidth 和 setHeight 方法。Square 类继承 Rectangle，并重写了 setWidth 和 setHeight，使其同时设置宽和高。那么，一个接收 Rectangle 参数并调整其宽高的函数，如果传入一个 Square 对象，就会得到错误的结果。</li> <li>修正： 重新考虑继承关系，或者让 Rectangle 和 Square 都实现一个 Shape 接口，而不是使用继承。</li> </ul> <h3 id="4-接口隔离原则">4. 接口隔离原则</h3> <ul> <li>核心思想： 客户端不应该被迫依赖于它不使用的接口。</li> <li>详细解释： 将一个庞大的、臃肿的接口拆分成更小、更具体的接口，使得客户端只需要知道它们感兴趣的方法。这样可以避免实现类被迫实现一些它们根本用不到的方法。</li> <li>比喻： 一台多功能打印机，有打印、复印、传真功能。如果做一个全能接口，老式打印机（只能打印）实现这个接口时，复印和传真方法只能空着或抛异常。不如拆分成 Printer、Scanner、Faxer 三个接口。</li> <li>违反示例： 一个 Animal 接口，有 eat(), fly(), swim() 方法。Dog 类实现它时，fly() 方法只能空实现。</li> <li>修正： 将 Animal 拆分为 Eatable, Flyable, Swimmable 等更精细的接口。Dog 实现 Eatable 和 Swimmable 即可。</li> </ul> <h3 id="5-依赖倒置原则">5. 依赖倒置原则</h3> <ul> <li>核心思想： <ul> <li>高层模块不应该依赖于低层模块，二者都应该依赖于抽象。</li> <li>抽象不应该依赖于细节，细节应该依赖于抽象。</li> </ul> </li> <li>详细解释： 要面向接口编程，而不是面向实现编程。这减少了类间的耦合性，提高了系统的稳定性。</li> <li>比喻： 你想读书（高层），你不应该直接依赖一本具体的纸质书（低层），而应该依赖于“书本”这个抽象概念。这样，无论是纸质书、电子书还是有声书，你都可以“读”。</li> <li>违反示例： UserService 类内部直接 new 了一个 MySQLDatabase 对象。如果将来要换用 OracleDatabase，就必须修改 UserService 的代码。</li> <li>修正： 定义一个 Database 接口。UserService 的构造函数接收一个 Database 类型的参数。这样，UserService 依赖于抽象的 Database，而 MySQLDatabase 和 OracleDatabase 都实现这个接口。</li> </ul> <h2 id="其他重要原则">其他重要原则</h2> <p>除了 SOLID，还有一些非常实用的原则。</p>