作为一个前端开发，对于23种设计模式，大家或多或少都有一点了解。但是，在项目开发中，大家是否有意识地去选择合适的设计模式去应用呢？
说实话，写本篇文章之前我没有。
最近想着让自己代码能变得跟优雅一点，所以特意去看了一下设计模式。
才知道，我在项目中，已经无意识地应用了一些设计模式。
第一个：策略模式
模式理解：策略模式定义了一系列算法或策略，并将每个算法封装起来。通过使用策略模式，可以在运行时根据需要选择不同的算法。
项目场景：页面中有多个tab，每个tab对应的数据接口都不相同，当时不想过多地使用if-else，然后就写下了如下图的代码。
现在回过头来看此段代码，可不就是借鉴了策略模式的设计思想嘛。
策略模式通过将我们的if条件改写为一条条的策略减少了if...else的数量，看起来更清爽，扩展起来也更方便。
但是参照策略模式来讲，我这段代码还是有点瑕疵的：
1.用1、2、3...来代表策略名，阅读不友好
2.没有将策略名入参，不便于其他页面调用
第二个：外观模式
模式概念：外观模式就是将模块一些内部逻辑封装在一个更高级的接口内部，或者将一些类似操作封装在一个方法内部，从而让外部调用更加方便。
项目场景：弹框中有多个表单项，大多表单项都需要在打开弹框时请求接口获取下拉值集。所以就将这些需要初始化的数据接口方法统一到一个方法中，如下图。
现在看来，图中代码写法正是体现了外观模式设计思想。
第三个：备忘录模式
模式理解：备忘录模式类似于JS经常使用的缓存函数，内部记录一个状态，也就是缓存，当我们再次访问的时候可以直接拿缓存数据。
项目场景：系统中用户树数据多个页面和弹框中都有用到，所以做了缓存，如果缓存里有就从缓存里取，如果缓存被清除了，则请求接口。
这里的备忘录模式是用本地缓存实现的，如果不用本地缓存方式，也可以用闭包的方式实现。
javascript
export function getNewUserTreeData() {
let cache = null
return async function() {
if(!cache) {
const res = await getNewUserTree();
cache = res
return res || {};
} else {
return Promise.resolve(cache[key])
}
}
}
// getUserData()方法无论调用多少次，均只请求一次接口
const getUserData = getNewUserTreeData();
getUserData();
getUserData();第四种： 单例模式
模式理解：单例保证一个类仅有一个实例，并提供一个访问它的全局访问点，主要用于管理全局变量，避免命名冲突和重复加载，同时也可以减少内存占用。
项目场景：代码中，我们经常以对象字面量的方式定义一个对象，供需要的地方使用。
对象字面量方式是最简单的单例模式，利用ES6的let和const不允许重复声明的特性天然实现。
以上就是我在项目中简单应用的一些设计模式，更多设计模式待后续观察与应用。