持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第1天，点击查看活动详情
前言
这两年，前端的发展太快太快（加上疫情裁员的影响，方方面面的都卷起来），加上笔者算是半路出道，总有一种被各种框架，新技术牵着鼻子溜得感觉。再加上沉沦公司业务代码苦海，尤其对于前端而言，面向对象和找对象一样遥远，在对数据的建模和业务的理解上欠缺严重（这边安利冴羽大大的一篇文章，前端为什么要学业务）。
痛定思痛，社畜自救。就先从设计模式入手了，试图理解前辈们的经验以及思想。 本系列预计有生之年系列，争取每周更新两篇~~ 咕咕咕
痛点
- 大家都知道这玩意很重要，但是在工作中可能不怎么会用到，最多也就是策略模式或者工厂，何况在代码工期太紧，能写完功能就谢天谢地了。
设计模式 什么设计模式，老夫写代码就是一把嗦 - 描述太过抽象，每个字都看的懂，但是连起来就不知道它在说什么。
依赖倒置原则（Dependence Inversion Principle，DIP）是指在设计代码架构时，高层模块不应该依赖于底层模块，二者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
- 没有万能的设计模式，每个模式都有利有弊，对选择困难症来说致命打击。
怎么入手
期待和各位小伙伴一起带着这几个问题一起看下去。
- 该模式解决了哪些特定领域的问题。
- 它的弊端是什么。
- 能在哪些业务场景中使用。
设计模式到底包含了哪些？
在笔者看来，设计模式除了23模式和6大原则之外，还包含了一些最佳实践的思路，或者说是思维方式，这些可能正是我们去理解设计模式的一些前置技能点。
设计模式的核心思想
设计模式解决的是“可复用”的设计问题，而类似可靠性设计、性能设计、安全性设计、可服务性设计等都不是设计模式能够解决的。
简单来说，设计模式从不同项目中总结出来的通用经验，是为了帮助我们快速理解现有的系统，并从中找出共性规律，如果没有足够的经验或者思考，反而容易引入错误的设计，造成更多的麻烦。 不发生变化的代码可以说是不存在的。我们能做的只有将这个变化造成的影响最小化 —— 将变与不变分离，确保变化的部分灵活、不变的部分稳定。 一个程序只做一件事，并做得很好。 听上去这条原则非常简单，但它实际上却能极大地降低软件复杂度。代码之间的相互影响越多，软件越复杂。这也就是我们常说的单一职责。 以上其实就是抽象与拆解，这部分也需要我们对业务有一定的熟练度和开发经验。具体的我们会在下文说明。
组合
对开发来说最常见的问题就是：需求不断变更导致不停的代码变更。。而这就有了两个概念解耦和模块化。 模块化 潜在的含义就是模块的一致性以及可替换。以做饭为例，每一个流程都把它标准化起来，在这个步骤中，我们替换调味（前提是要符合模块的定义规则，比如前置条件是调料找个抽象类，你不能放进去一个拖鞋）。通过变换调料/食材，就可以生产不同的料理。 解耦 把大程序变成小程序，把复杂的代码拆分成一个个不那么复杂的小代码。方便理清他们的关系。注意，程序间应该耦合在某个规范与标准上，而不是耦合在具体代码实现逻辑上。就比如乐高，我们判断他能组合的前提是基于乐高本身的接口（形状）。每块积木都是独立，只要符合了这个标准。我们就可以对他进行组合或者拼接。
分层
软件分层架构是通过层来隔离不同的关注点（变化相似的地方） ，以此来解决不同需求变化的问题，使得这种变化可以被控制在一个层里。比如常见的MVC。 而在前端，这两年出现的比较热门的概念BFF层的目的也是对业务逻辑的切割，对数据进行转发和处理。 分层解决解决了代码拆解和代码扩展的问题。 代码拆解 以前端目前的开发为例。用户在UI上点击下单，它需要经过UI层（页面）=> 业务层（对业务判断和发送请求）=>网关层(对请求进行拦截和处理，比如请求失败，token失效）等。我们相当于是把一个大的问题不断拆分一个个小问题来处理。UI层关注样式的呈现，业务层关系怎么下单，网关层只对请求负责。信。也就是说，不同阶段真正需要关注的问题其实变少了
提升扩展 分层架构可以将复杂的逻辑切分为多个层，这样大问题就变成了多个小问题，而我们可以很方便地解决每个小问题。每个小问题更容易被抽象为一个组件，当组件功能需要扩充或替换时，修改代码的影响也被有效地控制在有限的范围内，这样组件自身的复用性也就提高了。
总结 一句话概括就是 责任分离，降低耦合，标准制定和代码复用。 当然了，代码分层也会带来一些问题，比如代码量增多。开发成本变高，性能降低（执行链条过长）、代码复杂度提高（这边和代码拆解那边不冲突，局部的代码是简单化的，因为关注的问题变少了，但是在系统层面，复杂度因为层与层之间存在关联，复杂度提高）
面向对象
面向对象编程是一种编程范式，是基于部分特定编程语言下的编程经验总结，代表了程序员在编码时应该如何构建和执行程序的一种方法集合。 编程范式是一种根据功能对编程语言进行分类的方式，但它并不针对某种编程语言。 面向对象是为了抹平多人开发的差异性。尽可能解耦复杂的逻辑，即使是单体应用，也会抽象更多模块，让功能更容易被理解。 面向对象有三大特性：封装、多态和继承。从工程的角度来看最终目标都是加强代码可读性、可维护性、可扩展性，继承和多态的出发点都是“分离关注点”。使程序以最小的代价适应“关注点”的变化。即给对象分配职责来划分不同模块的功能，让各个模块的功能更聚焦在一个关注点上，这样当代码发生修改时，影响的范围几乎能很快被定位到。
在前端领域早期的业务相对简单，基本都是面向过程代码一把梭哈。但是在业务复杂的情况下，一把梭哈的代价就是无法维护也无法扩展。我们以视频播放这个功能为例，在早期设计的时候，可能只需要一个播放功能，那后续加入人脸识别，防快进拖拽功能，如果我们以面向过程的思路可能是直接硬编码集成在一块，那么后续在添加功能，或者移除功能（比如迁移到别的项目不需要人脸识别了）就会相当麻烦。
那我们可以抽象出一个播放的功能主模块基类，主要负责基础的播放功能。其次可以定义一些规则（接口，放假学规则等）。通过实现不同的接口来达到功能的扩展和迭代。其中的难点就是耦合规范与标准的制定。
总结
主要讲的就是对于设计理念的一些看法，笔者也是新人，有说的不对的地方也麻烦大家提出来哈，后续会详细介绍下六大设计原则再前端的应用。
