![[呲牙]](http://lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_2.cd1e2bd.png)
![[我想静静]](http://lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_74.d954f2d.png)
可恶的凡人啊
前端开发
获得徽章 0
![[流泪]](http://lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_6.dde0d83.png)
，这一顿32块，一小碗鸡汤十几块
赞了这篇沸点
关于设计模式的思考：
我之前认为，设计模式是锦上添花的东西，不深入去学习也没事。
但是我现在发现，设计模式的运用是否熟练，直接影响到解决问题的能力。
我举一个工作中遇到的真实的例子吧。
我封装了一个工作流，它只接收固定的参数A和B，A决定去哪里取数据，B决定将数据存到哪里
现在一个工作流需要同时进行两方数据的获取和存储
这个时候，其实只需要调用两次封装的工作流，并在每一次调用前增加适配即可——这个就是适配器模式的应用，代码逻辑不用进行任何改动就可以实现需求。
> 上面的方式符合开闭原则：对修改关闭，对扩展开放
如果没有想到适配器模式，可能会怎样去实现？
（这个其实就是我最开始的想法，现在想想其实很不优雅
）我们可以修改那个封装的工作流，允许传入多个参数。当然这样也能实现，只是这个方法明显涉及代码的改动，而改动就代表着使用到这个封装工作流的相关内容都需要进行相应的调整、测试、部署等等。而前者增加一个适配层即可，可能是几行代码、或者只是低代码中的一个节点。
还有一个好处，那就是了解设计模式之后，两个懂设计模式的人互相交流业务或者架构问题的时候，往往会特别高效。
比如A遇到一个问题，去问B，B说：“哦，这个用xxx模式可以解决”，然后A就懂了，说了谢谢之后直接开始疯狂输出，沟通就这样结束了。这整个沟通流程我只能用优雅来形容。
所以总的来说，设计模式很推荐学习！
我之前认为，设计模式是锦上添花的东西，不深入去学习也没事。
但是我现在发现，设计模式的运用是否熟练，直接影响到解决问题的能力。
我举一个工作中遇到的真实的例子吧。
我封装了一个工作流，它只接收固定的参数A和B，A决定去哪里取数据，B决定将数据存到哪里
现在一个工作流需要同时进行两方数据的获取和存储
这个时候，其实只需要调用两次封装的工作流，并在每一次调用前增加适配即可——这个就是适配器模式的应用，代码逻辑不用进行任何改动就可以实现需求。
> 上面的方式符合开闭原则：对修改关闭，对扩展开放
如果没有想到适配器模式，可能会怎样去实现？
（这个其实就是我最开始的想法，现在想想其实很不优雅
）我们可以修改那个封装的工作流，允许传入多个参数。当然这样也能实现，只是这个方法明显涉及代码的改动，而改动就代表着使用到这个封装工作流的相关内容都需要进行相应的调整、测试、部署等等。而前者增加一个适配层即可，可能是几行代码、或者只是低代码中的一个节点。还有一个好处，那就是了解设计模式之后，两个懂设计模式的人互相交流业务或者架构问题的时候，往往会特别高效。
比如A遇到一个问题，去问B，B说：“哦，这个用xxx模式可以解决”，然后A就懂了，说了谢谢之后直接开始疯狂输出，沟通就这样结束了。这整个沟通流程我只能用优雅来形容。
所以总的来说，设计模式很推荐学习！
展开
评论
7
赞了这篇文章
赞了这篇沸点
![[偷笑]](http://lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_20.7a46372.png)