JavaScript设计模式中的五大设计原则

大家好，我是苏先生，一名热爱钻研、乐于分享的前端工程师，跟大家分享一句我很喜欢的话：人活着，其实就是一种心态，你若觉得快乐，幸福便无处不在

github与好文

设计模式的好处

复用、易读、拓展

五大原则

开闭、接口隔离、里氏替换、依赖倒置、单一职责

开闭原则（hoc）

简写： ocp

要求：对拓展开发，对修改关闭

为了迎接元旦，产品想搞点新花样，把app里的a模块高亮，对b模块做打折处理

则代码如下

后来公司做年终总结，发现c模块一直在亏钱，故打算将其停用掉：置灰且显示停止发售

也很easy，如下即可

那要为了迎接春节又要将d特殊处理呢？元宵处理c呢......，你要说接着if...else，那我敬你是英雄，并奉上666

思考......

开闭原则要求关闭修改，这意味着我们不能直接去动原有的逻辑，那么是否可以把这些共有操作做一下归类呢？不管是置灰或者高亮或者默认颜色，都是对颜色的控制，所以可以提取一个setColor方法专门来做这件事；对于打折或停止销售或显示的金额都是一个div的文本显示，所以可以使用setSalary来做这件事

如此，对于新的mode来说，其天生就具有这两个方法，且可以在自身覆盖或增加自身的其他新的行为

单一职责（function）

简写： srp

要求：模块之间相互隔离，函数之间互不影响

比如我们做一个时间相关的下拉框，下拉框和时间就可以单独分开，使用moment来处理时间的转化

又比如对于开闭中列举的例子而言，假设有模块d不仅要高亮，而且要打折的话，则setColor和setSalary就是符合单一职责的。又或者是这样的

依赖倒置（vue.use）

简写： dip

要求：上层不应该依赖下层实现

假设我们要实现一个分享功能，我们可以这么写

这没毛病，将Share功能单独分开这很"单一职责"，通过在Mode内重写shareToWx也实现了"开闭"

后来，产品突然发现，在当下网购盛行，网民习惯性看评价下菜，光分享出去好像没什么卵用，那...加个评价？

好嘛，评价不是我写的，我就调一下，那一秒我就给他写完了

可是，这时候我有点头疼，倒不是bug多，而是我发现还可以优化：新用户注册直接给个折扣会不会更好？，如果产品也这样想，那我岂不是还要再改，WTMD...

我貌似，对下层产生了依赖...

如果能像vue一样提供一个插件机制就好了，不管传递给vue的插件如何改变，有多少个，都能够接收，并在适当的时候提供给页面调用，而不是在vue内部去保留一份实现

接口隔离

简写： isp

像elementUI、antd这些组件库，都提供了按需加载能力，这个其实从某种意义上来说就是接口隔离，因为对于不需要的功能我们不必要都跑一遍

里氏替换

简写： lsp

要求：子类可以继承并拓展父类，但不能破坏父类的执行流程，子类能出现的地方父类也可以

父类就像是在拟大纲一样，它实现了一个api的实现流程。子类可以直接使用也可以进行重写，但是不能破坏整体流程，如下，只有Fp是符合的

总结

本文是学习javascript设计模式的基础理论篇，如果大家对设计模块这一块儿的内容感兴趣，可以关注我，后续笔者会不定时对常见的23种设计模式进行更文哦🥰

---

如果本文对您有用，希望能得到您的点赞和收藏

订阅专栏，每周更新1-2篇类型体操，每月1-3篇vue3源码解析，等你哟😎