设计模式的好处
复用、易读、拓展
五大原则
开闭、接口隔离、里氏替换、依赖倒置、单一职责
开闭原则（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是符合的
