文章目录

• 概览
• • 设计模式
  • 设计原则
• 设计原则
• • Single Responsibility Principle：单一职责原则
  • Liskov Substitution Principle：里氏替换原则
  • Interface Segregation Principle：接口隔离原则
  • Dependence Inversion Principle：依赖倒置原则
  • Open Closed Principle：开闭原则
  • Demeter Principle：迪米特法则（最少知道原则）

概览

设计模式

设计模式分为三类：创造类型、结构类型、行为类型

• 创造型模式（Creational Patterns）
  • 单例（Singleton）模式
  • 原型（Prototype）模式
  • 工厂（FactorMethod）模式
  • 抽象工厂（AbstractFactory）模式
  • 建造者（Builder）模式
• 结构型模式（Structural Patterns）
  • 代理（Proxy）模式
  • 适配器（Adapter）模式
  • 桥接（Bridge）模式
  • 装饰（Decorator）模式
  • 外观（Facade）模式
  • 亨元（Flyweight）模式
  • 组合（Composite）模式
  • 过滤器（Filter Pattern）模式
• 行为型模式（Behavioral Patterns）
  • 模板方法（Template Method）模式
  • 策略（Strategy）模式
  • 命令（Command）模式
  • 职责链（Chain of Responsibility）模式
  • 状态（State）模式
  • 观察者（Observer）模式
  • 中介者（Mediator）模式
  • 迭代器（Iterator）模式
  • 访问者（Visitor）模式
  • 备忘录（Memento）模式
  • 解释器（Interpreter）模式

设计原则

设计原则

Single Responsibility Principle：单一职责原则

一个类只负责一个功能领域中的相应职责，就一个类而言，应该只有一个引起它变化的原因；从而实现高内聚、低耦合的指导方针。（高内聚：尽可能类的每个成员方法只完成一件事（最大限度的聚合）；模块内部的代码，相互之间的联系越强，内聚就越高，模块的独立性就越好。低耦合：减少类内部，一个成员方法调用另外一个成员方法，不要有牵一发动全身。

单一职责原则有什么好处：

• 类的复杂性降低，实现什么职责都有清晰明确的定义；
• 可读性提高，复杂性降低，那当然可读性提高了；
• 可维护性提高，可读性提高，那当然更容易维护了；
• 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做的好，一个接口修改只对相应的实现类有影响，对其它接口无影响，这对系统的扩展性、维护
  性都有非常大的帮助。

ps:接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。
单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口
或类设计得是否优良，但是“职责”和“变化原因”都是不可度量的，因项目而异，因
环境而异。

Liskov Substitution Principle：里氏替换原则

定义：Functions that use pointers or references to base classes must be able to
use objects of derived classes without knowing it.
（所有引用基类的地方必须能透明地使用其子类的对象。）
通俗点讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任
何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不
行了，有子类出现的地方，父类未必就能适应。controller-》service-》dao
定义中包含的四层含义：
1. 子类必须完全实现父类的方法
2. 子类可以有自己的个性
3. 覆盖或实现父类的方法时输入参数可以被放大
如果父类的输入参数类型大于子类的输入参数类型，会出现父类存在的地
方，子类未必会存在，因为一旦把子类作为参数传入，调用者很可能进入子类的方
法范畴。
4. 覆写或实现父类的方法时输出结果可以被缩小
父类的一个方法的返回值是一个类型 T，子类的相同方法（重载或覆写）的返
回值为 S，那么里氏替换原则就要求 S 必须小于等于 T，也就是说，要么 S 和 T
是同一个类型，要么 S 是 T 的子类。

Interface Segregation Principle：接口隔离原则

接口分为两种：

• 实例接口（Object Interface）：Java 中的类也是一种接口
• 类接口（Class Interface）：Java 中经常使用 Interface 关键字定义的接口

隔离：建立单一接口，不要建立臃肿庞大的接口；即接口要尽量细化，同时接口中
的方法要尽量少。
接口隔离原则与单一职责原则的不同：接口隔离原则与单一职责的审视角度是不相
同的，单一职责要求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划
分，而接口隔离原则要求接口的方法尽量少。

Dependence Inversion Principle：依赖倒置原则

是开闭原则的基础，

原始定义：

1. 高层模块不应该依赖低层模块，两者都应该依赖其抽象；
2. 抽象不应该依赖细节（实现类）；
3. 细节应该依赖抽象。
   依赖倒置原则在 java 语言中的体现：
4. 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是
   通过接口或抽象类产生的；
5. 接口或抽象类不依赖于实现类；
6. 实现类依赖接口或抽象类。
   依赖的三种写法：
7. 构造函数传递依赖对象（构造函数注入）
8. Setter 方法传递依赖对象（setter 依赖注入）
9. 接口声明依赖对象（接口注入）
   使用原则：
   依赖倒置原则的本质就是通过抽象（接口或抽象类）使各个类或模块的实现彼此独
   立，不互相影响，实现模块间的松耦合，我们怎么在项目中使用这个规则呢要
   遵循以下的几个规则就可以：
10. 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备
11. 变量的表面类型尽量是接口或者是抽象类
12. 任何类都不应该从具体类派生（只要不超过两层的继承是可以忍受的）
13. 尽量不要复写基类的方法
14. 结合里氏替换原则使用

Open Closed Principle：开闭原则

定义：
软件实体应该对扩展开放，对修改关闭，在程序需要进行扩展的时候，不能去修改原有的代码，实现一个热插拔的效果。
其含义是说一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来
实现变化。
软件实体：
项目或软件产品中按照一定的逻辑规则划分的模块、抽象和类、方法。
变化的三种类型：

1. 逻辑变化
   只变化一个逻辑，而不涉及其他模块，比如原有的一个算法是 ab+c，现在需要修
   改为 ab*c，可以通过修改原有类中的方法的方式来完成，前提条件是所有依赖或
   关联类都按照相同的逻辑处理。

2. 子模块变化
   一个模块变化，会对其他的模块产生影响，特别是一个低层次的模块变化必然引起
   高层模块的变化，因此在通过扩展完成变化时，高层次的模块修改是必然的。

3. 可见视图变化
   可见视图是提供给客户使用的界面，如 JSP 程序、Swing 界面等，该部分的变化
   一般会引起连锁反应（特别是在国内做项目，做欧美的外包项目一般不会影响太
   大）。可以通过扩展来完成变化，这要看我们原有的设计是否灵活。

Demeter Principle：迪米特法则（最少知道原则）

为什么叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。也就是说一个软件实体应当尽可能少的与其他实体发生相互作用。这样，当一个模块修改时，就会尽量少的影响其他的模块，扩展会相对容易，这是对软件实体之间通信的限制，它要求限制软件实体之间通信的宽度和深度

资料参考一
资料参考二
设计模式的7大原则详解
设计模式详解-刘伟

来源：追yi个小太阳