JS设计模式学习_基础篇

一、写在前面

设计模式的定义：在面向对象软件设计过程中针对特定问题的简洁而优雅的解决方案

当然我们可以用一个通俗的说法： 设计模式是解决某个特定场景下对某种问题的解决方案 。因此，当我们遇到合适的场景时，我们可能会条件反射一样自然而然想到符合这种场景的设计模式。

比如，当系统中某个接口的结构已经无法满足我们现在的业务需求，但又不能改动这个接口，因为可能原来的系统很多功能都依赖于这个接口，改动接口会牵扯到太多文件。因此应对这种场景，我们可以很快地想到可以用适配器模式来解决这个问题。

以上参考自 网易考拉前端团队-JavaScript设计模式

二、设计原则

设计哲学准则：

1. 小即是美
2. 让每个程序只做好一件事
3. 快速建立原型
4. 舍弃高效率而取可移植性
5. 采用纯文本来存储数据
6. 充分利用软件的杠杆效应（可复用）
7. 使用 shell 脚本来提高杠杆效应和可移植性
8. 避免强制性的用户界面
9. 每个程序都称为过滤器

小准则：

1. 允许用户定制环境
2. 尽量使操作系统内核小而轻量化
3. 使用小写字母且简写 list = ls
4. 沉默是金
5. 各部分之和大于整体
6. 寻求90%的解决方案

三、SOLID设计原则

• S 单一职责原则 single

  • 一个程序只做好一件事情
  • 如果功能复杂就拆分开，每个部分保持独立

• O 开放封闭原则 open

  • 对扩展开放，对修改封闭
  • 增加需求时，扩展新需求，而非修改已有代码
  • 这是软件设计的终极目标

• L 李氏置换原则

  • 子类能覆盖父类
  • 父类能出现的地方子类就能出现
  • JS使用较少

• I 接口独立原则

  • 保持接口独立，避免出现“胖接口”
  • JS中没有接口（ts）

• D 依赖导致原则

  • 面向接口编程，依赖于抽象而不依赖于具体
  • 使用方只关心接口而不关心具体类的实现
  • JS使用较少

四、23种设计模式

• 创建型设计模式
  是一类处理对象创建的设计模式，通过某种方式控制对象的创建来避免基本对象创建时可能导致设计上的问题或增加设计上的复杂度 。工厂模式、单例模式
• 结构型设计模式
  关注于如何将类或对象组合成更大、更复杂的结构，以简化设计 。适配器模式、装饰器模式、代理模式、外观模式
• 行为型设计模式
  用于不同对象之间职责划分或者算法抽象，行为型 设计模式 不仅仅涉及类和对象，还涉及类或对象之间的交流模式并加以实现 。观察者模式、迭代器模式、状态模式

五、UML类图

UML（Unified Modeling Language）是一种统一建模语言，为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。

5.1 类图的表示

类图分三层，第一层显示类的名称，如果是抽象类，则就用斜体显示。第二层是类的特性，通常就是字段和属性。第三层是类的操作，通常是方法或行为。前面的符号， + 表示public，- 表示private，# 表示protected （js中为严格区分，ts中有）

那么如何根据类图写出相应的代码结构呢？如下：

注：默认不添加属性或方法类型，即为 public，因此 public 可省略

5.2 类关系表示

• 泛化关系【继承】
  空心箭头表示，是一种继承关系。例如：自行车是车
• 聚合关系
  空心菱形箭头表示，是整体与部分的关系，与组合关系不同，整体和部分不是强依赖的。例如，部门撤销了，人员不会消失，他们依然存在
• 组合关系
  实心菱形箭头表示，是整体与部分的关系，但部分不能离开整体而单独存在。如公司和部门是整体和部分的关系，没有公司就不存在部门
• 关联关系【引用】
  实线（可带单/双箭头）表示，是一种拥有的关系，它使一个类知道另一个类的属性和方法

  

六、真题

1 根据下面的信息画UML类图

• 打车时，可以打快车或者专车。任何车都有车牌号和名称
• 不同车打车价格不同，快车1元/公里，专车2元/公里
• 行程开始时显示车辆信息
• 行程结束时显示打车金额

2 根据下面的信息画UML类图

• 某停车场，分三层，每层100车位
• 每个车位都能监控到车辆的驶入和离开
• 车辆驶入前，显示每层空余车位数量
• 车辆驶入时，摄像头可识别车牌号和时间
• 车辆出来时，出口显示器显示车牌号和停车时间

分析：

• 车是一个大类，快车和专车继承自车
• 行程是一个单独的类，连接用车和开始结束两个动作

分析：

• 关系1：车位组成层，层组成车库。组合关系
• 关系2：摄像机和显示屏是车库的部分，且能单独存在。聚合关系
• 车停入车位时，需要判别该车位状态（是否为空车位）
• 车库需要记录车驶入驶出的状态和记录车位数，需要通过层获取