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

[Aaron7Amelia]

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

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

[okayan]

推荐一本书，《敏捷软件开发——原则、模式与实践》
首先理解设计原则，然后再看设计模式，就很自然了

[litchinn]

我是通过别人的代码去体会到的设计模式的好处，第一次惊为天人，然后自然就想着怎么往自己的代码里套
说实话，如果你觉得这段代码用上设计模式是生搬硬套，那说明这段代码逻辑很简单，不需要设计模式，强行使用反而增加复杂度

[inrich0life]

2L 正解，只有真切被别人的代码恶心过，才能体会到它的好

[zjsxwc]

没什么特殊的，
如果写的是框架，那么多次迭代后自然而然会演化成用到设计模式，
如果不用设计模式这就不是框架，而是某某库。

[Leviathann]

就是被总结归纳出来的套路

[hellodigua]

说明没有需求，或者压根没有意识到某个逻辑竟然可以这样写，说白了还是没有经验。
平时还是应该多阅读一些开源代码，学习大佬的思路，2L 是说的对的，自己的代码现在看可能看不出来什么问题，但是你一年后再回过来看就会觉的这写的什么玩意，这时候就说明你代码的设计能力有了进步。

[across]

还没工作吧。
设计模式目的是写出清晰易维护的代码，业务接触多了，工程变大，协作人员变多，自然要考虑这个问题。跟着 bug 回溯问题想想，多半能找到优化点，有没时间去搞那是另一回事了。
自个儿小工程或独立代码段八成用不上，最多是记个概念。

[luob]

写单元测试就行了

你的目标是尽可能地让自己的代码每个函数只负责一件事，在有功能测试的那一层(甚至可以是 main 函数)才进行组合，且这种情况下还能很轻松地写出每个函数的单元测试。
这样不用死记硬背，你自己就找上门去了，23 个设计模式里起码有 20 个是为这个目标服务的

但是这只是个训练方法，并不代表现实场景，你都没有单元测试还用设计模式自己难为自己干啥。

[jeesk]

过度使用设计模式，对于新手非常不友好，参考 google juice, 里面特别多的设计模式。

[darkengine]

看 NB 项目的源码，我是看了 Android 源码之后才懂，几种常见的设计模式的最佳实践是这样的。

[wolfie]

多写轮子，硬写硬学 可能搞不懂实际场景。

[blankmiss]

同感 问题是找不到什么设计模式的最佳实践 没法看别人代码去学习，自己硬写硬套又感觉不对劲

[yifangtongxing28]

放心，赚钱的业务是不会因为你代码写的好赚钱的

[closedevice]

做的工程复杂度小了，找几个大的开源项目研究下，最好是参与进去

[dearmymy]

跟张无忌一样，学完设计模式就忘掉他，工作中遇到问题，突然自然想起来的时候，就是大功告成。

[p7534a]

非常厌恶这些装神弄鬼的概念，越来越恶心编程工作了

休假了半个月不见好转反而加重了

[cleveryun]

感觉编码有“结构”感时，就已经在用设计模式了，只是可能不知道叫啥，或者也不是书上说的那些中的一种。

[lmshl]

上大学时候我也曾迷信设计模式，还专门买了几本书学这个。结果每本书都没看过一半
现在工作十年了，对设计模式的需求几乎降到 0 了，反正没什么是现代函数式语言做不到的，硬套设计模式反而让代码变得难以维护。

[yqf0215]

代码写多一些，就会发现很多重复的功能，要修改某个功能很麻烦，要修改很多个地方。这时候就想能不能达到一个效果：把重复的功能提炼出来，只要写一遍，然后其他地方复用，以后只修改一个地方即可。
架构是干这个事情的。这依赖于要多写一些代码。
知其然，知其所以然，才行。硬学设计模式去套到代码中，是不行的，要有应用场景的需要才能理解。

[ksc010]

@luob 对 若想让你的代码具有“可测试性”，就会自然而然的用到设计模式了