****@design-pattern/patter

抽象和梳理编码过程中使用的设计模式，持续增加中..

如何使用

1. 进入目录安装依赖

npm i @design-pattern/patter --save

2. 引入项目进行使用

import { StateMachine, t } from '@design-pattern/patter/state'

enum State {
  idle = 1 << 0,
  start = 1 << 1,
  stop = 1 << 2,
}

enum Event {
  start = 1 << 0,
  stop = 1 << 1,
}

interface Callback {
  [Event.start]: () => void
  [Event.stop]: () => void
}

const stateMachine = new StateMachine<State, Event, Callback>(
  State.start,
  [
    t(State.idle, Event.start, State.start, () => {}),
    t(State.start, Event.stop, State.stop, () => {})
  ]
)

void stateMachine.dispatch(Event.start)

现有内容

1. 行为模式

• 命令模式
• 状态模式
• 事件模式

学习资料

• 图说设计模式
• 设计模式之美

理论知识

1. 面向对象

1.1. 四大特性

封装、抽象、继承、多态

1.2 类之间关系

• 泛化（Generalization）表示B继承A

  classDiagram
  direction RL
  classA <|-- classB

• 实现（Realization）表示B实现A的相关接口

  classDiagram
  direction RL
  class classA
  <<interface>> classA
  classA <|.. classB

• 组合（Composition）强依赖，生命周期相同，表示 A 由 B 组成

  classDiagram
  direction RL
  classA *-- classB

• 聚合（Aggregation）弱依赖，生成周期不同，表示 A 由 B 组成

  classDiagram
  direction RL
  classA o-- classB

• 关联（Association）一般A成员变量包含B，方向代表 A知道B，但是B不知道A

  classDiagram
  direction RL
  classA --> classB

• 依赖（Dependency） A 依赖 B，一般 A 中方法接收 B

  classDiagram
  direction RL
  classA ..> classB

1.3 设计&开发

• 面向对象分析（OOA）
  • 需求一般都比较抽象、模糊，需要你自己去挖掘，做合理取舍、权衡、假设，把抽象的问题具象化，最终产生清晰的、可落地的需求定义。需求定义是否清晰、合理，直接影响了后续的设计、编码实现是否顺畅。所以，作为程序员，你一定不要只关心设计与实现，前期的需求分析同等重要。
• 面向对象设计 （OOD）
  • 划分职责进而识别出有哪些类
  • 定义类及其属性和方法
  • 定义类与类之间的交互关系
  • 将类组装起来并提供执行入口
• 面向对象编程 （OOP）
  • 参考上一步设计的 UML 图进行实现

2.设计原则

• SOLID原则-Single Responsibility Principle 单一职责原则
• SOLID原则-Open/Closed Principle 开闭原则
• SOLID原则-Liskov Substitution Principle 里式替换原则
• SOLID原则-Interface Segregation Principle 接口隔离原则
• SOLID原则-Dependency Inversion Principle 依赖倒置原则
  • 控制反转（IOC）：这里的“控制”指的是对程序执行流程的控制，而“反转”指的是在没有使用框架之前，程序员自己控制整个程序的执行。在使用框架之后，整个程序的执行流程可以通过框架来控制。流程的控制权从程序员“反转”到了框架。除此之外，还有模版模式等众多设计模式
  • 依赖注入（DI）：不通过new()的方式在类内部创建依赖类对象，而是将依赖的类对象在外部创建好之后，通过构造函数、函数参数等方式传递（或注入）给类使用。
  • 依赖反转原则（DIP）：依赖反转原则也叫作依赖倒置原则。这条原则跟控制反转有点类似，主要用来指导框架层面的设计。高层模块不依赖低层模块，它们共同依赖同一个抽象。抽象不要依赖具体实现细节，具体实现细节依赖抽象。
• DRY原则、KISS原则、YAGNI原则
• LOD法则
  • 迪米特原则（Law of Demeter, LoD）又称为最少知识原则（Principle of Least Knowledge），是一种用于软件系统开发中的设计指南，目的是为了降低系统中不同类之间的耦合。原则的核心思想是“只和你的直接朋友通信” （当前对象本身（this）、作为方法参数传递给当前对象的对象、当前对象的成员变量对象、当前对象在方法中创建或实例化的对象）

3. 规范和重构

3.1. why、what、when、how

• 重构的目的：为什么重构（why）？ 对于项目来言，重构可以保持代码质量持续处于一个可控状态，不至于腐化到无可救药的地步。对于个人而言，重构非常锻炼一个人的代码能力，并且是一件非常有成就感的事情。它是我们学习的经典设计思想、原则、模式、编程规范等理论知识的练兵场。
• 重构的对象：重构什么（what）？ 按照重构的规模，我们可以将重构大致分为大规模高层次的重构和小规模低层次的重构。大规模高层次重构包括对代码分层、模块化、解耦、梳理类之间的交互关系、抽象复用组件等等。这部分工作利用的更多的是比较抽象、比较顶层的设计思想、原则、模式。小规模低层次的重构包括规范命名、注释、修正函数参数过多、消除超大类、提取重复代码等等编程细节问题，主要是针对类、函数级别的重构。小规模低层次的重构更多的是利用编码规范这一理论知识。
• 重构的时机：什么时候重构（when）？ 我反复强调，我们一定要建立持续重构意识，把重构作为开发必不可少的部分，融入到日常开发中，而不是等到代码出现很大问题的时候，再大刀阔斧地重构。
• 重构的方法：如何重构（how）？ 大规模高层次的重构难度比较大，需要组织、有计划地进行，分阶段地小步快跑，时刻让代码处于一个可运行的状态。而小规模低层次的重构，因为影响范围小，改动耗时短，所以，只要你愿意并且有时间，随时随地都可以去做。

3.2 重构重要方法

看修改代码会不会牵一发而动全身。除此之外，还有一个直接的衡量标准，也是我在阅读源码的时候经常会用到的，那就是把模块与模块之间、类与类之间的依赖关系画出来，根据依赖关系图的复杂性来判断是否需要解耦重构。