设计模式原则

单一职责原则 (SRP)

定义

一个对象或者方法只做一件事情

当我们在实现一个方法的时候,如果这个方法有两个或多个动机去改写这个方法，那么就不符合单一职责原则。单一职责原则里面的职责，其实就是改变该方法的动机，也就是引起该方法变化的原因。如果一个方法里两个职责耦合在一起，那么当修改代码的时候，一个职责变化就可能会影响其他职责，这样是不安全的

应用的设计模式

代理模式，单例模式，迭代器模式，装饰者模式

如何分离职责

并不是所有的职责都需要一一分离，如果当变化的时候，有两个职责总是会同步变化，那么这两个职责就没有分离的必要，或者是两个职责耦合在一起，但是他们跟本没有改变的预兆，那么这两个职责也不需要分离

优缺点

优点：降低了对象的复杂度，将对象拆成了更小的粒度，有利于代码的复用以及单测。当一个职责变化的时候不会影响其他职责
缺点：对象拆分，那么就会一定的增加其相互联系的难度，增加了编写代码的复杂度

最少知识原则 (LKP)

定义

一个软件的实体应当尽可能的少与其他实体发生相互作用，也就是对象与对象之间尽可能的减少联系交互。如果不需要彼此直接通信的话，就可以搞一个中间者，来代替两个对象进行联系

一个模块或者对象将内部的数据或者实现细节进行隐藏，只暴露出一个接口 API 供外界来访问，这样就可以让其之间的联系限制在最小范围之内

举个简单的 🌰 子：页面中接口在请求的时候，需要带上用户信息的参数，但是，获取到用户信息的参数是一个单独的模块，这样的话，用户信息里面的实现细节不需要关注，只需要这个模块最后提供一个获取到用户的 API，然后在其他模块调用这个 API 就可以使用，并不在他是如何去获取信息的，请求的接口是什么。这些都不在乎

应用的设计模式

外观模式，中介者模式

优缺点

减少了对象之间的联系和依赖
但是可能增加一些庞大的难以维护的第三者对象，用于处理对象之间的通信

开放-封闭原则 (OCP)

里氏替换原则

依赖倒置原则

接口隔离原则

合成复用原则

设计模式

外观模式

其实外观模式就像是一种高层的封装，他定义了一个高层的接口，然后调用这个接口可以使得子系统更容易使用，隔离了调用者和其子系统内部的细节，符合最小知识原则

外观模式屏蔽了一组子系统的复杂性，然后提供了一个简单易用的高层接口，当然如果提供的这个接口并不能满足，那么也可以直接越过这个高层接口，来直接去调用子系统里的一些方法。注意:外观模式里面封装了一组子系统，这一个个子系统都是相互独立的

比如: 我们打开编辑器的时候，需要手动打开编辑器的日志，编辑器的欢迎页，编辑器的编辑区，那么我们利用外观模式，直接封装一个打开编辑器的方法。

const openLog = () => {
  // 打开日志里的一些处理逻辑
};

const openWelcome = () => {
  // 打开欢迎页里的一些处理逻辑
};

const openEdit = () => {
  // 打开编辑区里的一些处理逻辑
};

const openView = () => {
  openLog();
  openWelcome();
  openEdit();
};

openView();

当提供的高层接口不能直接满足的时候，我们可以直接调用子系统来使用

优缺点

为一组子系统提供了一个简单访问的入口
隔离了客户与复杂子系统的联系，客户并不需要了解子系统的细节，即使修改了子系统，只要外观不变，就不会影响到客户的调用，而且外观的修改也不会影响到子系统
可复用性变低