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

[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 对 若想让你的代码具有“可测试性”，就会自然而然的用到设计模式了

[hsfzxjy]

设计模式只是对特定编程语言缺陷的补充，不用奉为教条。

[MeiJM]

如果是 java 的可以看看 spring 里面用到了很多设计模式 有些特性就是设计模式的封装 例如事件监听 但是也有很多过度设计 例如权限的结构就很乱

[wzcloud]

多看看优秀的开源框架，就体会到设计模式的好处了。

[mauve]

移动端开发必须要用，又没有刷新网页或者加机器这种操作，App 卡死就是死了，没救

[fkdog]

设计模式细分大概有 17 种，实际上大部分本质都是封装 /继承 /多态的使用罢了，本质实际上都是一样的。
如果你能通过利用面向对象的这几个特性来达到降低耦合、便于扩展和维护，那背不背其实都无所谓

[fkdog]

不要背，背了也没用。
很多人刷 leetcode 、学 jdk 、spring 框架源码、设计模式，都是边学边忘。
学习的最好方式就是实践。
如果你只是为了应付面试，那么就在准备面试的时候再去突击这些东西。
如果你是为了把这些东西利用到平时代码里，那么可以边学边做。

[makelove]

@hsfzxjy 当年精读过最初四人帮的那本模式书，有些模式还是挺有高级感的，并不是针对语言缺陷（或者可以说只有极小部分可能和语言不太动态有关）

[xuanbg]

设计模式其实就是针对特定的问题的最优解。说白了就是“套路”。

[charlie21]

设计模式其实是责任划分方式

[inframe]

软件工程这块就是千层饼，一层套一层

对设计模式我的理解是

软件开发过程中 [软件模块内部] 常见共性结构问题的解决方法，组织代码的公共套路，就像看到一元二次方程先算解的Δ=b²-4ac 一样，
就算不用设计模式大概率也能写代码，但优化到最后就是类似的某一个模板即设计模式了

设计模式的千层饼的维度高一阶就是架构模式了，最近看了本《凤凰架构，作者周志明》感觉这些问题就很类似

[Rocketer]

29 楼正解。

设计模式就是写代码的时候假设我就只负责这一小块，我怎么写才能让别人调用方便，且别人增加和修改需求的时候尽量不需要我也跟着修改。

常思考这个问题，最终你会发现你已经实现了某个（些）设计模式。可能与课本上不完全一致，但方向是对的，此时再按教科书的方式修改一下你的代码，你就彻底记住了。

[netabare]

说到设计模式的话……想到了小学时候的平方差公式，不知道这个比喻恰当不恰当。

大概是，在课本上会讲到，但是其实也不是多么复杂的知识，也许很多人在学到这个知识点之前，就已经自己摸索出来了。

但是反过来说，也不会有人整天写书本、课程或者是开会来教授「平方差公式背后隐藏了什么精神」之类的东西吧？

我对设计模式的理解大抵上也差不多……首先这东西在某些特定的场景是有用的，但是并不是什么绝对真理一样的东西，反过来说，不同人也可以通过自己的实践和学习形成或多或少的属于自己的感悟。

但是如果有人整天在吹「 Java 编程思想」、「 PHP 设计模式」之类的东西……还是离得远远的吧。

顺便提一下，有一些设计模式的存在，是为了解决在语言中缺少的语法结构而出现的。

比如说 Visitor 模式之于 Pattern Matching 。在 Kotlin 这种命令式语言里面不存在 PM ，所以只能用 Visitor 来模拟。

比如说 Strategy 模式之于 Lambda 和 HOF ，所以这种模式在 Java8 之后就没什么价值了。

比起死记硬背设计模式，不如尝试理解一下这些模式是怎么来的。

这背后涉及到的，Language Design Engineering ，还有 Functional Programming 里面的抽象和组合的概念，也许可以获得更多有趣的收获。

[NGXDLK]

这东西不是死记硬背，你可以先把设计模式过一遍，脑子里留个印象，真正要用的时候能有个方向。随着实践的次数增多，慢慢就理解了。

[openmm]

@fkdog 哈哈哈哈，我的理解和你一样

[darling19961030]

各种设计思想、理论、方法都是针对具体问题的分析或者总结，并没有形成一套完整的面向对象设计体系。javaee 在 spring 这种 mvc 模式下，大多是事务脚本式代码，面向过程，分析过程类似 wbs 这种拆分步骤。楼上提到责任划分，我认为这是封装带来的好处，隔离复杂度,责任明确，而设计原则，是指导怎么设计这些静态的类，比如单一职责，设计模式，是指导怎么动态组织这些类。

[tramm]

需要时自然就懂了, 不懂说明还不需要.

[lllllliu]

可以增加 KPI （狗头）

[ren2881971]

个人感觉是因为语言的不健全才引入设计模式啊。。

[7911364440]

第一次感受到设计模式的好处是看自己当时的技术经理写的代码，对比了下自己写出来的类似的代码，拓展性和代码复用性简直强太多了。
所以 2L 是正解，多看看优秀的代码能学到很多东西。

[Chinsung]

设计模式理解的方式一方面是看源码，不是看他设计模式怎么实现的，看他解决了什么问题抽象了什么
不要试图去找本书学会，真正悟到的一瞬间是你发现当下写的代码感觉很复杂，然后开始回忆之前看过的的某种模式可以简化这个逻辑，这才是你真正悟到设计模式的时候，设计模式本身也就是某种情况的某种套路写法

[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 有些好的开源项目，在设计模式上很有讲究，应该是都是有经验的大佬写的，写的代码是需要经得起吐槽的。