此专题中包含7种设计原则，23种设计模式的介绍。

设计模式是一套快被写烂了的编码技巧。随便找找都能找到大量的书和博客。但是基本上都是用很大的篇幅来介绍设计模式的实现、优点、缺点等等。举的一些例子也是与实际开发基本不相干的例子。基于此，我才决定写一系列设计模式的博文，不仅要把设计模式的原理讲清楚，还要结合实际，找出实际的应用案例。如哪些设计模式用在了Spring框架或MyBatis框架中，在我的职业生涯中，哪些业务场景用了哪些设计模式解决。理论结合实践学习起来才最有效。

所以我将本系列博文命名为《设计模式实践》，在后续的文章中我将结合市面上的优秀的设计模式相关的书、国内外一些博主关于设计模式的文章以及AI来全面的分析设计模式原理及其应用，同时结合今后参与的项目，不断完善案例。给大家带一套有深度的设计模式文章。

设计原则

• 单一职责原则(Single Responsibility Principle, SRP)
• 开闭原则(Open-Closed Principle, OCP)
• 里氏代换原则(Liskov Substitution Principle, LSP)
• 依赖倒置原则(Dependency Inversion Principle, DIP)
• 接口隔离原则(Interface Segregation Principle, ISP)
• 合成复用原则(Composite Reuse Principle, CRP)
• 迪米特法则(Law of Demeter, LoD)

定义

Clients should not be forced to depend upon interfaces that they don’t use.
客户端不应该依赖那些它不需要的接口

核心思想

记得几年前有一位很厉害的前辈说过：软件设计是什么，就是“分离关注点，消除重复”。这句话一直影响这我，而我做软件设计也是朝着这两个方向努力。而接口隔离原则最核心的就是拆分，即分离关注点。

定义

High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.

• 高层模块不应该依赖于低层模块，两者都应该依赖于抽象。
• 抽象不应该依赖于细节。细节应该依赖于抽象。

简而言之就是“面向接口编程”。

定义

里氏替换原则是Barbara Liskov^[1]与1988年提出来的。原文是：

What is wanted here is something like the following substitution property: If for each object of type S there is an object of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when is substituted for then S is a subtype of T

如果对每一个类型为$S$的对象$O_1$， 都有类型为$T$的对象$O_2$， 使得以T定义的所有程序P在所有的对象$O_1$都代换成$O_2$时， 程序 P 的行为没有发生变化， 那么类型$S$是类型$T$的子类型。

另一种说法是：

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

所有引用基类的地方必须能透明地使用其子类的对象。

定义

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification
软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。

核心思想

开闭原则的核心思想就是抽象。开闭原则的主要目的就是为了让我们在不修改源码的情况下来扩展系统的功能。

核心思想

定义

A class should have only one reason to change. （ 就一个类而言，应该仅有一个引起它变化的原因）

每一个职责都是变化的一个轴线（an axis of change）。当需求变化时，该变化会反映为类的职责变化。如果一个类承担了多于一个的职责，那么引起它变化的原因就会有多个。

如果一个类承担的职责过多，就等于把这些职责耦合在了一起。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生是，设计会遭到意想不到的破坏。

引用自：《Agile Software Development, Principles, Patterns, and Practices》

关于这句话中的 “类的变化” 是指什么，书中并没有给出明确的说明。从字面上来理解的话应该是指类的代码的修改。

那么单一职责的作用是什么呢？我认为主要有以下几点：

1. 降低类的复杂度
2. 使代码的可读性和可维护性提高。
3. 降低业务的耦合度，使某项业务修改时只需要关注一个点，而不是整个业务链。（后面举例说明）