对与设计模式始终都没有什么感觉

[Aaron7Amelia]

现在有书籍或者博客会用各种比喻来说各种设计模式。但是我看了后始终都没有什么感觉。最早先的时候，我还特意的死记硬背，想把 23 种设计模式记住。写代码的时候，硬着头皮往某个模式套。但在没有感觉的前提下，死记硬背实在太难受，然后过了一段时间就又全都忘记了。

不知道大家是如何学习或者应用设计模式的

[mwjz]

设计模式不是新的东西，是一种总结，一般 3 年工作经验就自然而然写的出来，只是 GoF 大佬们将各种场景下都总结了一遍，具象化了。
我当初看的时候也是蒙蔽，那时候没有实际工作经验，后来真实工作碰到各种场景时自然而然就懂了。

[unco020511]

当你用它解决过一个问题,或者让你的代码看起来非常舒服后,或许就有一些感觉了

[witcherhope]

看项目业务是否足够复杂，设计模式本质上是转移复杂度的，因为复杂度不会消失，只能转移

[CaffreySun]

得其意，忘其式，即为大成。

[rm0gang0rf]

用得着 自然就会了，用不着会了也没用
应用型人才找对位置更重要

[ProgrammerAlan]

@inrich0life 太赞同了

[weizhen199]

让傻逼们不要写傻逼代码的规范。
你 NB 你可以创造设计模式。

[xloger]

「设计模式」最重要的其实是最开始的那几条原则，这是软件设计的核心，而后续 23 种设计模式只是上述原则在特定场景特定语言下的一个范例。

想学设计模式，最理想的情况下就是你自己埋头写完一个项目，找个资深开发审查你项目，这里该用什么什么，那里该用什么什么，这样做的好处是什么。
然后经过你的思考对比，自然就领悟了设计模式。

其次再是多用和感受优秀的第三方框架。比如我刚毕业时用自己封的图片缓存框架，然后偶然用了 Glide 后看它的接口设计惊为天人。优秀常用的设计模式自然在优秀的项目中常有体现，多学习即可。


再最后，具体到 Java ，其实很多设计模式是为了解决 Java 语言的局限，和基于旧代码不变动的拓展。用任何一个设计模式前一定要想清楚：它是为了解决什么问题？它是怎么地解决这个问题？
然后再结合你用的语言或者工具，看有没有其他更简单的方式解决。

[vitoliu]

设计模式就好比写论文列梗概，熟能生巧，或者多学习一些框架的代码，后面自然随便一写就跟设计模式一样了，springboot 里面关于 Env 的代码有不属于常用设计模式的设计，一样很优雅。

[littleEight]

如果不是天才或者人才的话，首先你得在敲代码的领域实践一万个小时，让大脑全方面收集相关信息，等这个过程结束后，你再回头来看设计模式，是多么得美好~~

[Features]

我用的最多，印象最深刻的是工厂模式
因为这个真的很有用

[SeaTac]

没有合适的场景光靠死记硬背没感觉很正常
进个好点的公司 pr 被毒打几次就懂了

[slert]

早年看过一本挺厚的讲设计模式的书 23 种模式基本就是围绕着设计原则在做变化 记住设计原则更重要点 以后写代码的时候 可能就会无意中写成某一种设计模式
但是讲真 如果不是造轮子之类的 能写到值得用设计模式那种复杂度的代码的机会可能不多

[allgy]

必须解决问题才能体会模式

[libook]

都是工具，不需要没必要硬上，需要了就会觉得好用。你可以不用了解每种模式具体怎么用，而是先了解每种模式适合在什么情境下解决什么问题，等遇到了一样的情境和问题你就可以去学习一下并利用起来了。

[fresco]

我的经验是多看比人的代码 从优秀的代码里面学习总结 单看设计的书 确实是理解不了 只能有个大概的概念

[whileFalse]

我在知道设计模式这个词之前写了很多代码。然后听说有这么一本书很牛逼，随便翻了翻。哦，就是把我用过的一些方法起了个名字。

到现在我也没仔细学过设计模式。但我知道：
同样类型的代码，在不同量级下，应该用不同的设计方式。

一个项目就你一人写，统共仨接口，瞎逼写就完了。如果是仨人一人写三十个接口，就得好好弄弄了。

[sampeng]

设计模式是学的么？是练的。
没 10 万代码量，设计模式就是个噱头

[windliang]

如果是前端的话，之前总结过一些工作中用的，供参考： https://pattern.windliang.wang/

[solitude2]

@hellodigua 有些好的开源项目，在设计模式上很有讲究，应该是都是有经验的大佬写的，写的代码是需要经得起吐槽的。