目次
背景
遇到了什么事情
计划理念
学习意义
计划目的
根本原则
solid原则
单一职责（SRP）
开放封闭原则（OCP）
里氏替换原则（LCP）
接口隔离原则（ISP）
依靠倒置原则（DIP）
最小知识原则
前端必会的计划模式
创建型
单例模式
工厂模式
布局型
装饰器模式
适配器模式
代理模式
举动型
观察者模式
发布订阅模式
模板模式
策略模式
总结
背景
“计划模式没什么用，真正计划框架的又有几个人呢”。在我个人看来，话是没错，不学习计划模式对日常开发工作几乎产生不了多大影响。那我为什么要写计划模式呢？是由于我自己经历了几件事情，让我越来越觉得计划模式重要了，而且我以为肯定要学习，那么接下来像品茶一样品一下计划模式吧！
遇到了什么事情
Scene1:上半年做了个复杂的会员卡的知识付费需求，在做会员权益的课程列表时，利用了列表卡片的公共业务组件，要扩展时发现核心逻辑代码全都簇拥在一个代码块，想要加一个新的范例需要每一行代码都读一下甚至打断点调试一下，还有可能会遗漏某些场景，函数职责太大，修改轻易影响原有逻辑。
Scene2:前段时间代码评审时发现，无论是汗青代码还是版本代码，总是发现有一大堆if...else和switch...case逻辑，中心一大片代码块光看代码缩进都眼晕，如果新增一条新的又要写一条判断分支，可读性和扩展性都比较差。
Scene3:有个版本需求是做一个AI的视频编辑器，在开发计划阶段，大佬提出启一个新的工程，以包的方式引入到各个利用的业务中，虽然前期要做一些基建，但是做到了整体将编辑器与其他业务模块分离，从多场景，跨产品的利用结果看来，若不是大佬和坚持与远见，我们可能要为了某一个利用场景花大量时间调试和扩写，无疑表现了大佬的功力和田地。
计划理念
根据上述经历，我发现大多数人缺少的并不是开发本事，而是耐打的计划本事，大佬之所以可以或许未雨绸缪，一方面是由于大佬项目经验丰富，另一方面是由于大佬的架构思维和计划理念超前。
学习意义
- 解决复杂问题，对于简朴问题不能滥用，否则更复杂。
- 提升整体代码质量，让“屎山”不堆积或者少堆积。
- 为各个框架、库的源码阅读提供思想上的支持。
- 面试时思维更开阔，答复更有深度。
计划目的
我们学习计划模式的终极目的是为了尽可能让程序简洁而优雅，需要计划出高复用和易扩展的应用程序。
- 高复用：高复用指的是我们的应用程序，如类、函数、组件等，可以或许简朴复用，秉持着一个原则，能复用的就不要自己再写了，节省时间和成本。
- 易扩展：易扩展指的是我们的应用程序在计划时，要做到未雨绸缪，根据计划原则而且留有一些扩展坑位，在扩展时不影响现有逻辑，克制写一个功能影响多个功能。
根本原则
- 封装：顾名思义，将类、方法封装，把功能与功能之隔断离，相互不受影响。
- 面向接口：接口是类成员和举动的束缚，所以依靠于抽象而不依靠于具体的类，如许可以包管易扩展性。
- 组合优于继承：继承固然重要，许多场景利用继承会痴肥累赘，如写一个不重要但必须有的功能有可能继承了一个包含许多其他功能的基类，所以在这种场景下，组合的思想就极其重要了，是机动的接口和抽象类发挥作用的地方。
solid原则
solid原则是计划模式总结出来的最佳实践，有五个原则分别是单一职责、开闭原则、里氏替换、接口隔离和依靠倒置，取每一个英文单词的首字母，称为solid。
单一职责（SRP）
一个类、函数，只负责一件事情。如许做为了克制功能耦合，修改一处功能波及其他功能。
SRP虽然是solid原则中最简朴最根本的，但也是最有技能含量的，技能含量泉源于分离代码的计划。有的场景需要分离，如列表分页功能的页数厘革逻辑和数据业务逻辑；有些场景不需要分离，如一些工具方法，可以传字符串也可以传字符串数组，没须要分离的原因也有肯定的计划理念，降低利用者的心智负担。
开放封闭原则（OCP）
类、函数、模块等，应对扩展开放，对修改封闭。这个原则更多是为了让我们有一个扩展性思想，鼓励我们扩展而不是修改原有逻辑，克制修改旧代码引入新错误。
里氏替换原则（LCP）
子类的实例对象可以替换父类的实例对象，这个原则是夸大了继承的思想，鼓励子类完全实现父类的举动，如许才可以或许无缝替换。
接口隔离原则（ISP）
接口而应该细颗粒度以及具体化，不发起痴肥的接口，有效减少了用户在实现某个接口的举动时依靠许多用不到的功能。
依靠倒置原则（DIP）
面向接口编程，鼓励利用接口和抽象类，从抽象到具体，而不是直接就是具体的实现。在许多计划模式中会引入一个中心人的角色，从而实现业务逻辑和数据访问的解耦。
最小知识原则
也叫迪米特法则，在类、函数、模块之间通信时，实体应仅与最近的实体通信而非更远的，且两个实体之间尽可能少的了解相互。
前端必会的计划模式
常见的经典计划模式有23种，由于JavaScript并不是标准的以类为基础的面向对象编程语言，但随着ECMAScript和TypeScript的发展，JavaScript也支持了以类为基础的写法。如ES6中的class、ES2020中的私有成员。
前端依附着个人明白，“前端必会的计划模式”系列中分享一些对于前端而言重点要掌握的计划模式，代码均利用TypeScript实现。
创建型
创建型计划模式提供一种创建对象的方式，使代码机动可扩展。
单例模式
单例模式，包管一个类只能有一个实例对象，唯一的访问点。核心思想是通过限定实例数量，包管全局唯一，便于管理和维护。
传送门：【前端必须掌握的计划模式——单例模式】
工厂模式
工厂模式，通过工厂提供的统一接口来得到实例对象，具体创建逻辑在工厂，客户端只需要调用工厂方法即可。大抵有三种变体，简朴工厂、工厂方法、抽象工厂。工厂方法是简朴工厂的优化，抽象工厂更适合多维度创建。
传送门：【前端必须掌握的计划模式——工厂模式】
布局型
布局型计划模式更注重体系布局，将类和对象组成更大的布局，同时保持机动和可扩展。
装饰器模式
装饰器模式，是一种组合思想，可以将对象放入特别对象中，从而绑定新举动。用这种方式到达一种面向切面的状态，利于模块之间解耦。
传送门：【前端必须掌握的计划模式——装饰器模式】
适配器模式
适配器模式，让不兼容的对象可以转换成兼容的对象，利用了中心人角色，扮演适配器，将不兼容的对象通过适配器的包装后，告竣兼容目的。
传送门：【前端必须掌握的计划模式——适配器模式】
代理模式
代理模式，让外界与中心人通信，中心人扮演代理，内部对外界信息进行辨认，有效信息与系统内部交互，无效信息过滤掉。
传送门：【前端必须掌握的计划模式——代理模式】
举动型
举动型计划模式主要研究对象与对象之间通信，如何安全高效做职责分配。
观察者模式
观察者模式，定义一种订阅的机制，当事件实行后，会发送给全部的观察者，观察者们可以自行处理事件消息。
传送门：【前端必须掌握的计划模式——观察者模式】
发布订阅模式
发布订阅模式，属于对观察者模式的优化和升级，引入了一个中心人转发消息，从而使发布者和订阅者各司其职。
传送门：【前端必须掌握的计划模式——发布订阅模式】
模板模式
模板模式，在父类中定义一个流程，子类继承重写来包管顺序，不修改原有布局。
传送门：【前端必须掌握的计划模式——模板模式】
策略模式
策略模式，封装一些逻辑功能，在调用时可以根据参数值进行选择替换。
传送门：【前端必须掌握的计划模式——策略模式】
总结
计划模式是一把双刃剑，可以用来提升代码质量，但也可以提高代码复杂度，需要善加利用。具体问题具体分析，不能滥用也不能只用那么一两种，他们各有千秋，无法确定哪个计划模式最好，适合项目环境的才是最好的。前端必须掌握的计划模式专栏到此已完结，如果对您有帮助可以点个赞点个关注哦！
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
