这是一个创建于 665 天前的主题，其中的信息可能已经有所发展或是发生改变。
大佬们在实际开发中是怎么做的？我学习了一些设计模式，但是到了实战的时候，除了单例模式、工厂模式，好像其他很多设计模式从来没用过，难以活学活用～，感觉白学了。
有经验的大佬们给赐教一下，让我摆脱 crud boy 吧。。
 |
1
dilu 2023-02-22 11:36:23 +08:00  9
个人觉得，真的不要用复杂的设计模式。
单例工厂啥的就算了，之前业务代码有人用了观察者模式，策略模式，一大堆的接口跳来跳去又不好定位，除了一开始的作者，根本没几个人在不花时间的情况下面看得懂，需求又急，只能瞎写一通，破坏了之前的设计模式。 设计模式是好的，但是国内情况下，复杂的设计模式在业务中真的不太实用。 |
 |
2
thinkershare 2023-02-22 11:36:55 +08:00
摆脱 crud boy 并不是应用设计模式就能解决的。你需要去学习的代码设计 /模块设计 /架构设计一整套东西，生搬硬套设计模式是没啥意义的。
|
 |
3
nackily 2023-02-22 11:42:06 +08:00
就设计模式而已，抱着为了用而去学的心态是不合适的，很可能适得其反，当然常见的静态工厂 /单例 /享元等除外。
|
 |
4
BingoXuan 2023-02-22 11:45:05 +08:00
最近在业务中实践了观察者模式。代码确实更简洁了，减少很多中间变量和判断处理。但使用时候要手动管理观察者，有时候我都不确定某个变量被谁观察了。后来想了一下，还是实现的方法不够优雅。等下一版再改
|
 |
5
king888 2023-02-22 11:47:35 +08:00
工厂模式！安排下面得人干活
|
 |
6
nielinjie 2023-02-22 11:51:34 +08:00
不严格地讲，很多设计模式是为变化准备的，如果你在自己的编码工作中多想想系统今后的变化，就会发现很多设计模式是必要的。
|
|
7
nackily 2023-02-22 11:52:24 +08:00
就设计模式而已，抱着为了用而去学的心态是不合适的，很可能适得其反，当然常见的静态工厂 /单例 /享元等除外。可以学也应该学，毕竟不能一直 crud 吧，模式是需要基础支撑的，不然真就是生搬硬套，尬得一匹。多看多练，反复看反复练，就我个人的经验来说，最重要的其实是看框架源码，很多框架源码如果你不了解设计模式，是很难看透彻的，等你了解了一个模式的脉络之后，再回过头去看难度会降低不少，要多想作者为啥要用这个模式在源码中，这样等你以后遇到类似的场景就能引入进来。另设计模式更像是方法论，需多温习，在不同的能力阶段，会有不一样的感受和见解。
|
 |
8
opengps 2023-02-22 11:55:50 +08:00 3
不要过于迷信设计模式，很多时候你重复的代码写多了，随着自身技术提升就不知不觉用上了设计模式。
比如单例，说白了是个线程安全的全局公用变量。 等到能力差不多了，再去回顾下课程，改造那些早就已经不是简单代码堆积状态的业务逻辑。 |
 |
9
Leviathann 2023-02-22 14:11:57 +08:00
通用答案是学习 scala3
|
 |
10
blackmolycat 2023-02-22 14:19:33 +08:00
你把 spring 看一遍就知道怎么应用了呀，用到了一堆设计模式
|
 |
11
iamqk 2023-02-22 14:25:30 +08:00
设计模式确确实实需要应用在编码中
要花些时间，多多重构和思考自己的开发内容 设计模式能够有效而简洁的对程序作出解释 没有设计模式的代码 自己可能今天可能看懂 可是后天再看，或者别人来看 就是一坨大便了 |
|
12
iamqk 2023-02-22 14:29:22 +08:00
设计模式要想得到应用
首先你要熟练掌握各种设计模式的定义 然后要熟记理解各种设计模式的应用场景及简单代码，达到熟练才能灵活应用，比如乘法口诀的程度 次后你要在设计中不停的提醒自己是否能将熟练掌握的设计模式得以应用 最后在你闲暇的时间，重新阅读代码，重新思考需求以及代码的结构，是否能用设计模式进行重构 |
 |
13
clf 2023-02-22 14:32:29 +08:00 1
我个人觉得设计模式在“基础服务”里用的更多。
一般可以把系统拆分为 基础服务、业务服务。基础服务提供基建类功能（如表单引擎、流程引擎等），此类服务往往需要能够支持外部根据业务做拓展，需要能够和其他服务低耦合。所以在基础服务设计的时候往往会用到很多的设计模式。 业务服务相对来说和业务强关联，如果业务逻辑基本没有太大的可变性，那么就没必要硬上设计模式。而如果后续可能会有很多的“灵活性”那再考虑设计。 相对来说 SaaS 化的设计模式用武之地会比私有化部署的定制系统多很多。 |
 |
14
xiang0818 2023-02-22 14:49:21 +08:00
如果是基础性的组件用设计模式是可以的，因为改动的少，kpi 要求。如果是业务的话，怎么简单怎么来，怎么让人快速理解，怎么来
|
 |
15
echo1937 2023-02-22 15:36:07 +08:00
@dilu 我也认同不要滥用设计模式，并且做好相关的模式说明，但是我感觉观察者模式，策略模式应该不属于你所说的复杂的设计模式。
单从可维护性来说，你举的这个例子如果能做到文档说明，应该是利大于弊的。我们这边有个反例，一个复杂的业务，场景很多大家都按自己的方式写，后来遇到了需求变更，所有人都开始手忙脚乱地改代码，然后有些地方因为上面的同事已经离职了只能后面的人硬啃代码，这改起来真的要死人。 这时候我感觉当初定好设计模式，相当于对所有人的一种规约，能极大避免出现某些情况。 |
 |
16
dwlovelife 2023-02-22 15:47:31 +08:00
单说设计模式，大部分人是水平不行，所以代码水平根本达不到设计一说，就是 if else 一把缩，但是不可否认的是好的设计，在某一个地方恰如其分的用好了一个设计模式，是可以降低后期的维护成本的, 最常用的就是策略、抽象模版、责任链，工厂，这打几个吧。多看看开源，那些说不要用特别复杂的设计模式，我不赞同，如果你要建一搜摩天大楼，可能为了复用为了灵活为了就得高度抽象，就得跳来跳去，难不成因为要跳来跳去，自己水平不行，就写成 if else, 等下一个人来就会说写的什么屎山，自己往往说别人的时候是屎山。到自己设计的时候又嫌复杂度高，真的笑了。切勿自己学了设计模式就要生搬硬套，这样我是不赞同的。
|
 |
17
darkengine 2023-02-22 16:02:30 +08:00
主要是大部分项目的寿命都到不了需要上设计模式去保证可维护性
|
 |
18
furlxy 2023-02-22 16:08:47 +08:00
熟悉业务后再根据掌握的设计模式进行修改甚至重构，没有哪种设计模式可以直接生搬硬套的。
|
 |
19
zgl263885 2023-02-22 16:21:06 +08:00
孙子兵法有啥用?你要是俩人打架斗殴用不着这玩意儿,但两国战争,是不是就有用了呢?高启强不学孙子兵法,就凭他的那点墨水儿能上位?
书到用时方恨少,学了设计模式是在你遇到问题时候,给你提供一些大佬前辈们解决问题比较好的思路. 当然,不能生搬硬套,不能为用设计模式而用设计模式,而是此处用了后会为项目带来较大好处的时候使用,如降低代码数量,提高代码可读性,提供运行效率,提高可维护性,可扩展性等等; 至于 crud boy,这个是个趋势,设计模式的一大应用场景就是各种框架的设计开发中,然后让用这些框架的人,只需要会 crud,就能完成工作,甚至一些低代码平台连 crud 代码都不用写了;如果你觉得你用不到那些设计模式,就取各种框架的源代码中看看吧; |
 |
20
a0210077 2023-02-22 16:35:34 +08:00
看自己写的或项目的代码能否有套用一种或多种设计模式，使得代码更简洁，更好应对需求添加变更
最终达到新模块需求到手，一看便知该如何设计，自己却说不出来用了哪个模式 摆脱 curd boy ，可以用空闲时间自己写小工具玩玩 |
 |
21
tool2d 2023-02-22 16:49:19 +08:00
设计模式并不是给 crud 用的，你需要对自己日常的业务做上层抽象。
比如用各种 DSL 配置文件去替代代码判断，java 用在业务端挺多，也挺擅长做这些的。 |
Select Language