5
如何把设计模式应用到实际工作？
source link: https://www.v2ex.com/t/918186
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
大佬们在实际开发中是怎么做的？我学习了一些设计模式，但是到了实战的时候，除了单例模式、工厂模式，好像其他很多设计模式从来没用过，难以活学活用～，感觉白学了。
有经验的大佬们给赐教一下，让我摆脱 crud boy 吧。。
16 条回复 • 2023-02-22 15:47:31 +08:00
 |
dilu 4 小时 19 分钟前 个人觉得，真的不要用复杂的设计模式。
单例工厂啥的就算了，之前业务代码有人用了观察者模式，策略模式，一大堆的接口跳来跳去又不好定位，除了一开始的作者，根本没几个人在不花时间的情况下面看得懂，需求又急，只能瞎写一通，破坏了之前的设计模式。 设计模式是好的，但是国内情况下，复杂的设计模式在业务中真的不太实用。 |
5 |
thinkershare 4 小时 19 分钟前 摆脱 crud boy 并不是应用设计模式就能解决的。你需要去学习的代码设计 /模块设计 /架构设计一整套东西，生搬硬套设计模式是没啥意义的。
|
 |
nackily 4 小时 14 分钟前 就设计模式而已，抱着为了用而去学的心态是不合适的，很可能适得其反，当然常见的静态工厂 /单例 /享元等除外。
|
 |
BingoXuan 4 小时 11 分钟前 最近在业务中实践了观察者模式。代码确实更简洁了，减少很多中间变量和判断处理。但使用时候要手动管理观察者，有时候我都不确定某个变量被谁观察了。后来想了一下，还是实现的方法不够优雅。等下一版再改
|
 |
king888 4 小时 8 分钟前 工厂模式！安排下面得人干活
|
 |
nielinjie 4 小时 4 分钟前 不严格地讲，很多设计模式是为变化准备的，如果你在自己的编码工作中多想想系统今后的变化，就会发现很多设计模式是必要的。
|
|
nackily 4 小时 3 分钟前 就设计模式而已，抱着为了用而去学的心态是不合适的，很可能适得其反，当然常见的静态工厂 /单例 /享元等除外。可以学也应该学，毕竟不能一直 crud 吧，模式是需要基础支撑的，不然真就是生搬硬套，尬得一匹。多看多练，反复看反复练，就我个人的经验来说，最重要的其实是看框架源码，很多框架源码如果你不了解设计模式，是很难看透彻的，等你了解了一个模式的脉络之后，再回过头去看难度会降低不少，要多想作者为啥要用这个模式在源码中，这样等你以后遇到类似的场景就能引入进来。另设计模式更像是方法论，需多温习，在不同的能力阶段，会有不一样的感受和见解。
|
 |
opengps 4 小时 0 分钟前 不要过于迷信设计模式，很多时候你重复的代码写多了，随着自身技术提升就不知不觉用上了设计模式。
比如单例，说白了是个线程安全的全局公用变量。 等到能力差不多了，再去回顾下课程，改造那些早就已经不是简单代码堆积状态的业务逻辑。 |
 |
Leviathann 1 小时 44 分钟前 通用答案是学习 scala3
|
 |
lgjx123 1 小时 36 分钟前 你把 spring 看一遍就知道怎么应用了呀，用到了一堆设计模式
|
 |
iamqk 1 小时 30 分钟前 设计模式确确实实需要应用在编码中
要花些时间，多多重构和思考自己的开发内容 设计模式能够有效而简洁的对程序作出解释 没有设计模式的代码 自己可能今天可能看懂 可是后天再看，或者别人来看 就是一坨大便了 |
|
iamqk 1 小时 26 分钟前 设计模式要想得到应用
首先你要熟练掌握各种设计模式的定义 然后要熟记理解各种设计模式的应用场景及简单代码，达到熟练才能灵活应用，比如乘法口诀的程度 次后你要在设计中不停的提醒自己是否能将熟练掌握的设计模式得以应用 最后在你闲暇的时间，重新阅读代码，重新思考需求以及代码的结构，是否能用设计模式进行重构 |
 |
clf 1 小时 23 分钟前 我个人觉得设计模式在“基础服务”里用的更多。
一般可以把系统拆分为 基础服务、业务服务。基础服务提供基建类功能（如表单引擎、流程引擎等），此类服务往往需要能够支持外部根据业务做拓展，需要能够和其他服务低耦合。所以在基础服务设计的时候往往会用到很多的设计模式。 业务服务相对来说和业务强关联，如果业务逻辑基本没有太大的可变性，那么就没必要硬上设计模式。而如果后续可能会有很多的“灵活性”那再考虑设计。 相对来说 SaaS 化的设计模式用武之地会比私有化部署的定制系统多很多。 |
 |
xiang0818 1 小时 6 分钟前 如果是基础性的组件用设计模式是可以的，因为改动的少，kpi 要求。如果是业务的话，怎么简单怎么来，怎么让人快速理解，怎么来
|
 |
echo1937 20 分钟前 @dilu 我也认同不要滥用设计模式，并且做好相关的模式说明，但是我感觉观察者模式，策略模式应该不属于你所说的复杂的设计模式。
单从可维护性来说，你举的这个例子如果能做到文档说明，应该是利大于弊的。我们这边有个反例，一个复杂的业务，场景很多大家都按自己的方式写，后来遇到了需求变更，所有人都开始手忙脚乱地改代码，然后有些地方因为上面的同事已经离职了只能后面的人硬啃代码，这改起来真的要死人。 这时候我感觉当初定好设计模式，相当于对所有人的一种规约，能极大避免出现某些情况。 |
 |
dwlovelife 8 分钟前 单说设计模式，大部分人是水平不行，所以代码水平根本达不到设计一说，就是 if else 一把缩，但是不可否认的是好的设计，在某一个地方恰如其分的用好了一个设计模式，是可以降低后期的维护成本的, 最常用的就是策略、抽象模版、责任链，工厂，这打几个吧。多看看开源，那些说不要用特别复杂的设计模式，我不赞同，如果你要建一搜摩天大楼，可能为了复用为了灵活为了就得高度抽象，就得跳来跳去，难不成因为要跳来跳去，自己水平不行，就写成 if else, 等下一个人来就会说写的什么屎山，自己往往说别人的时候是屎山。到自己设计的时候又嫌复杂度高，真的笑了。切勿自己学了设计模式就要生搬硬套，这样我是不赞同的。
|
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK