我认为这主要有两个原因：
设计模式迫使我们用其术语进行思考。换句话说，几乎不可能发明新东西（也许更好）。
设计模式不会永远持续下去。语言和技术日新月异；因此，设计模式最终将变得无关紧要。
因此，了解如何在没有任何特定模式的情况下正确编程并不要学习它们就变得更加重要。
重点还在于通常，当人们遇到问题并且没有太多时间时，他们会尝试使用一种模式。这意味着只需稍作更改即可将现有代码复制并粘贴到您的项目中，以使其正常工作。当需要更改或添加某些内容时，开发人员不知道从哪里开始，因为这不是他的代码，而且他对它也不是很熟悉。
#1 楼
为了我的钱，我认为每个人都错过了设计模式的要点。我很少想知道在给定情况下应该使用哪种模式。另外，我早在知道它们的名称之前就使用了其中的大多数模式。设计模式的强大功能在于交流。对于我来说，说“使用一种策略”比详细描述我的建议要快得多。如果我们都知道胖域模型与交易脚本的好处，那么我们就更容易争论这两个术语的含义。依此类推。
最重要的是，如果我已命名一个FooBuilder类，那么您知道我正在使用Builder模式来生成我的Foo。
如果您不知道我说的是“观察者模式最适合”的意思，那么您可以轻松地将其搜索到Google上。
设计模式的力量永远不会消失。
评论
+1表示“我很早就使用了大多数模式，直到我知道它们的名字。”它们都已经存在了很长时间了，只是没有模式命名法。早在1991年，我就用C编写单例，并向经验丰富的程序员展示了一个实例，该程序员以前从未见过它，并且认为它很漂亮。
–鲍勃·墨菲（Bob Murphy）
11年4月24日在17:54
但是，模式也会消失。在1950年代，“子程序调用”是一种非常流行的模式。在C语言中，“对象”是（某种程度上）流行的模式。由于它们被现代语言所吸收，并且（在子例程的情况下）甚至被现代CPU的指令集所吸收，所以它们实际上都已绝迹。
–Jörg W Mittag
2011年4月25日下午4:59
@Bob Murphy：Argh Singleton :( :( @（@ pdr：确切地说，模式是关于编程的交流。因为几乎适合模式而应用模式是一个人可能犯的最大错误，因此不应在模式方面进行设计反思，他们只应在解释您的想法时才进入设计：“除了我进行了微调外，它几乎像一个
– Matthieu M.
2011年5月6日在18:48
@Jorg：“子例程调用”模式何时消失。您认为方法/函数调用是什么？
–扣篮
2012年2月9日在15:55
@Dunk：当然，这取决于您使用的语言。我不知道您使用的是哪种语言，但是在我今天使用的所有语言中，子例程调用都是内置的语言功能，而不是设计模式。但是，例如在C语言中，方法调用是一种设计模式，而在Java语言中，它是一种内置语言功能。
–Jörg W Mittag
2012-2-10 12:43
#2 楼
模式具有两个主要目的：可预测地解决张力：模式旨在以已知的方式解决一组特定的张力。 Smalltalk最佳实践模式的作者肯特·贝克（Kent Beck）将模式描述为重复专家在类似情况下将做出的决定的一种方式。只要紧张局势保持不变（而且经常如此），解决紧张局势的模式就将仍然有用。传播力乘数：模式使我们可以多说几句。他们利用了少量强大而易于理解的概念，这些概念适用于各种问题空间。 @pdr的答案完全取决于模式的传播价值。
评论
紧张是什么意思？
– StackedCrooked
20-10-1在11:04
#3 楼
我认为设计模式会阻碍创新的说法是完全错误的。您应该知道已经存在的地方，因此不需要重新发明轮子。因为只是暂时的，所以模式整体上适用于OOP系统，并且没有链接到任何特定的平台或语言。现在，当人们谈论模式时，我不喜欢的是某些人对某种模式有痴迷跟他们。我曾经有一个客户要我“至少还要包含两个模式”（WTF ？！），因为由于我的代码中缺少流行词，所以看起来不够精打细算。
评论
我的经验是，编写良好的代码完全符合多种设计模式，因为它们描述了良好的实践。因此，为了满足您的客户，应该只是确定您已经在使用哪些客户并将他们的名字放在文档中。简单！
–研究员
2011-04-24 15:34
@Donal研究员那就是我所做的:)我最终找到了发现模式并命名了它们，从而给项目带来了圆满的结局。我最大的问题是，这是一个非常非常小的项目（大约一个星期的工作）并且非常简单：它从怪异的数据格式中读取数据，进行了两次转换，将数据绘制成图形并将其存储到数据库中。
–Vitor Py
2011-4-24 15:39
@Vitor我完全同意你的看法。我个人认识一些人，认为寻找适合您的问题/方案的设计模式是一个坏主意！他们更喜欢重新发明轮子。我担心他们可能有一天醒来，请我不要使用Java IO类并编写自己的IO处理程序！
–CKing
2013年2月26日19:17
#4 楼
反模式的概念也许是紧密相关的。我不认为研究设计模式是成为软件工程师的关键步骤。软件设计很重要，通常保留为项目中软件架构师的特权，但实际上，可以在众所周知的“井井有条”的团队中达成共识来完成某些事情。但是设计模式和反面模式构成了这些讨论的资源。一个人需要欣赏一些行之有效的经验教训，以及如何利用（或减轻）设计选择的后果。一个好的团队可以提出自己的词汇来进行此类讨论，但是引用曾经去过那里的作者制定的事实上的标准确实不是一件坏事。
评论
“反模式”只是对“坏”的长期委婉说法。
–迈克尔·肖（Michael Shaw）
14年2月13日在0:23
@hardmath“反模式”的意义远不止是“坏”
– GoatInTheMachine
17年5月30日在12:49
@GoatInTheMachine：我同意，那是对我的帖子的评论。虽然反模式是应避免的示例，但它们具有使它们成为有吸引力的设计选择的特征。有时有意识地遵循反模式，知道其缺点和陷阱是合理的。
– Hardmath
17年5月30日在12:55
#5 楼
有两种设计模式：通用模式，这是有关如何组织复杂程序以使您完全理解它们的更多内容。这些并没有消失，尽管可能会发现更多示例。
情境模式，它们被约束（例如编程语言）所引起的特定力量所束缚，以至于当这些力量改变，它们变得无关紧要。
好吧，可以说所有的模式都是有情境的，但是有些力量来自现实世界，有些力量来自工具。工具的变化远比现实世界快。
评论
所有模式都是通过它们解决某种紧张关系的方式来定义的。只要紧张关系相同（并且经常如此，这就是它们成为模式的原因），这些模式将仍然有用。
– Rein Henrichs
2011年5月6日15:06
@Rein：但是造成紧张局势的力量可以是内部的或外部的。不同的语言具有不同的内在力量（例如，与接口有关的模式对Java而言比对C ++更重要，因为它们的类系统之间存在不同的张力）。
–研究员
2011年5月6日15:10
绝对是浏览一下实现模式（肯特·贝克（Kent Beck）的Java模式书），可以看出通用模式与更特定于Java特性的模式之间的分布相当均匀。将该书与Smalltalk最佳实践模式进行比较也可以发现。
– Rein Henrichs
2011年5月6日15:12
#6 楼
阅读设计模式就像学习数学，而不是重新发明它们。一旦您对以前的工作有了深刻的了解，就不会阻止您在某个领域取得重大进展。您认为Rieman从未读过Euclid吗？#7 楼
当设计模式减少您的同事或客户花在“这是如何工作的”上的时间时，这对设计模式是有好处的。即使出于标准化的目的而强制执行标准也没有意义，但如果有一种通用且易于理解的方法来执行某项操作，则每当编码人员寻找希望找到并执行该模式的模式时，您就已经做好了自己的工作更容易。#8 楼
我相信，由四个人组成的帮派将设计模式分类为对常见问题的通用解决方案*
所以是的，当发生相同类型的问题时，它们是相关的。这给我们带来了术语“设计模式”的问题。模式是可以识别的重复发生的事物。因此，实际上没有设计模式，就存在问题模式。
某些编程语言可能对某些问题有本机解决方案。 “设计模式”一书本身提到，如果您使用的是CLOS，则访问者模式的价值很小，因为CLOS本身就支持多调度，这正是来访者模式试图解决的问题。
.NET框架还具有内置事件机制，可将事件发布到多个侦听器，从而使Observer模式在这种情况下不那么重要。
从台式机应用程序到Web应用程序的变化**改变我们必须解决的编程问题的类型。 “设计模式”一书中的许多模式与桌面应用程序相关，而与Web应用程序无关。当然，对于单页应用程序，这些模式在客户端可能再次有用。
但是设计模式以及诸如“设计模式”或“企业应用程序体系结构模式”之类的书都是当您是新手程序员并第一次面对新型问题时，它具有巨大的价值；因为我是第一次被要求实现撤消功能。如果不是《设计模式》这本书的作者，我的实现可能就像是在每次状态更改操作之后存储数据快照***一样-一种极易出错且效率极低的方法。 >
所以是的，随着时间的流逝，某些模式变得越来越不相关，并且当您成为经验丰富的程序员时，您对它们的考虑就更少了。但是对于新手来说，它们是有价值的，只要您记住它们是解决问题的方法-而不是寻求使用尽可能多的方法。
*报价可能不是100％根据我的经验，它是准确的
**，对于企业来说，为内部业务线应用程序选择Web交付机制已经变得非常普遍。
***在学习了函数式编程和函数式数据结构之后，那么实际上这可能就是我今天要解决的方法。
#9 楼
过度遵守设计模式可能是有害的-模式已被记录为解决常见问题的解决方案，但它们不是说明手册。但是，仅仅因为对它们进行了详尽的讨论，并且在某些情况下将其应用于有效的问题域之外，并不意味着它们毫无价值。它们是设计程序的体系结构时要借鉴的一组原则（称为框架），从而使架构师对他/她希望看到解决方案的工作方式印象深刻。一个优秀的开发团队将它们视为功能的基础，而不是功能规范。评论
这似乎没有提供任何实质性的解释和解释
– gna
2014年11月2日，9：03
评论
如果应用模式意味着复制和粘贴现有代码，那么您可能做错了使用设计模式！=货物崇拜编程
这个问题的标题可以改写为“现在不是真的在重新发明轮子吗？”
设计模式迫使我们以其术语进行思考-如果您愿意的话。对模式的了解使我可以考虑给定设计问题的可能性。通常，这就像阅读餐厅菜单...“不，不，有趣，不，嗯，哈！”。此外，现代语言功能通常使几十年前成文的特定模式图变得过时。
developers.stackexchange.com/questions/9219/…相关。