如今，设计模式真的必不可少吗？

我正在阅读“编码员在工作”，并且面对这样一个事实，书中接受采访的一些专业人员对设计模式并不那么热心。

我认为有两个主要原因：

1. 设计模式迫使我们以其术语进行思考。换句话说，几乎不可能发明新的东西（也许更好）。

2. 设计模式不会永远持续下去。语言和技术日新月异；因此，设计模式最终将变得无关紧要。

因此，也许更重要的是学习如何在没有任何特定模式的情况下正确编程，而不要学习它们。

重点还在于，通常当人们遇到问题并且没有太多时间时，他们会尝试使用一种模式。这意味着只需稍作更改即可将现有代码复制并粘贴到您的项目中，以使其正常工作。当需要更改或添加某些内容时，开发人员不知道从哪里开始，因为这不是他的代码，而且他对代码也不是很熟悉。

为了我的钱，我认为每个人都错过了设计模式的要点。我很少想知道在给定情况下应该使用哪种模式。另外，在我知道它们有名字之前，我就已经使用了大多数这些模式。

设计模式的力量在于交流。对于我来说，说“使用某种策略”比详细描述我的建议要快得多。如果我们都知道胖域模型与交易脚本的好处，那么我们就更容易争论这两个术语的含义。等等。

最重要的是，如果我已命名一个FooBuilder类，那么您就会知道我正在使用Builder模式生成Foo。

即使您不知道当我说“观察者模式非常适合该问题”时在说什么，您也可以轻松地对其进行搜索和搜索。

从这个意义上说，设计模式的力量将永远不会消失。

设计模式是对我们作为软件人使用的通用语言表达能力的增强。这种通用语言不是必不可少的，但是它使对问题的许多通用解决方案更容易表达。例如，谈论Singleton比谈论“只应具有一个实例，但不能使其成为静态和全局实例的类”要容易得多。

设计模式提供的解决方案很有用，但是如果您遇到解决方案，您可能已经想到了这些解决方案。了解设计模式需要一定的成熟度-如果您从未解决过问题，则不会看到解决方案的价值或兴趣。

模式有两个主要目的：

• 可预测地解决张力：模式设计为​​以已知的方式解决一组特定的张力。Smalltalk最佳实践模式的作者肯特·贝克（Kent Beck）将模式描述为一种重复专家在类似情况下做出的决定的方式。只要紧张局势保持不变（并且经常如此），解决紧张局势的模式将仍然有用。

• 沟通力乘数：模式使我们可以说很多话。他们利用了一小部分功能强大且广为人知的概念，这些概念适用于各种问题空间。@pdr的答案完全取决于模式的交流价值。

我认为设计模式阻碍创新的肯定是完全错误的。您应该知道已经存在的地方，因此无需重新发明轮子。对于临时而言，模式总体上适用于OOP系统，并且未链接到任何特定平台或语言。

现在，当人们谈论模式时，我不喜欢的是有些人对模式有些执迷。我曾经有一个客户要我“至少还要包含两个模式”（WTF ？！），因为由于我的代码中缺少流行词，所以看起来不够精进。

反模式的概念也许是紧密相关的。我不认为研究设计模式是成为软件工程师的关键步骤。软件设计很重要，通常保留为项目中软件架构师的特权，但实际上，可以通过众所周知的“井井有条”的团队达成共识来完成某些事情。

但是设计模式和反模式构成了这些讨论的资源。一个人需要欣赏一些行之有效的经验教训，以及如何利用（或减轻）设计选择的后果。一个好的团队可以提出自己的词汇来进行此类讨论，但是引用曾经去过那里的作者制定的实际标准并不是一件坏事。

有两种设计模式：

1. 通用模式，更多有关如何组织复杂程序，以便您完全了解它们。这些并没有消失，尽管可能会发现更多示例。
2. 情境模式被绑定到由约束（例如编程语言）引起的特定力量中，以至于当这些力量发生变化时，它们就变得无关紧要了。

可以，可以说所有模式都有些情况，但是有些力量来自现实世界，有些力量来自工具。工具的变化远比现实世界快。

阅读设计模式就像学习数学，而不是重新发明它们。一旦您对以前的工作有了深刻的了解，就不会阻止您在某个领域取得重大进展。您认为里曼从未读过欧几里得吗？

当设计模式减少您的同事或客户花在思考“这是如何工作的”上的时间时，这对设计模式是有好处的。即使出于标准化的目的而强制执行标准也没有意义，但是，如果有一种通用且易于理解的方法来执行某项操作，则每当编码人员寻找希望找到并执行该模式的模式时，您就已经做好了自己的工作更轻松。

我相信四个人将设计模式归类为

常见问题的通用解决方案*

因此，是的，当发生相同类型的问题时，模式是相关的。这给我们带来了术语“设计模式”的问题。模式是可以识别的重复发生的事物。因此，实际上没有设计模式，而有问题模式。

对于某些问题，某些编程语言可能具有本机解决方案。“设计模式”一书本身提到，如果您使用的是CLOS，则访问者模式的价值很小，因为CLOS本身就支持多调度，这正是访客模式试图解决的问题。

此外，.NET框架具有内置事件机制，可将事件发布到多个侦听器，从而使Observer模式在此上下文中的相关性降低。

从桌面应用程序更改为Web应用程序**，也改变了我们必须解决的编程问题的类型。“设计模式”一书中的许多模式与桌面应用程序相关，而与Web应用程序无关。当然，对于单页应用程序，这些模式在客户端可能再次相关。

但是，当您是新手程序员并首次遇到新型问题时，设计模式以及诸如“设计模式”或“企业应用程序体系结构模式”之类的书就具有巨大的价值。因为我是第一次被要求实现撤消功能。如果不是《设计模式》这本书的作者，我的实现可能就像是在每次状态更改操作之后存储数据快照***一样，这是一种非常容易出错且效率极低的方法。

因此，是的，随着时间的流逝，某些模式变得越来越不相关，并且当您成为经验丰富的程序员时，您对它们的考虑就更少了。但是对于新手来说，它们是有价值的，只要您记住它们是解决问题的手段-而不是寻求使用尽可能多的手段。

*报价可能不是100％准确，因为它是从内存中提取的

**根据我的经验，企业为内部业务线应用程序选择Web交付机制已经变得非常普遍。

***在学习了函数编程和函数数据结构之后，那么实际上这可能就是我今天要解决的方法。

过度遵循设计模式可能是有害的-模式已被记录为解决常见问题的解决方案，但它们不是说明手册。但是，仅仅因为对它们进行了详尽的讨论，并且在某些情况下将其应用于有效的问题域之外，并不意味着它们毫无价值。它们是设计程序的体系结构时要借鉴的一组原则（称为框架），从而使架构师对他/她希望看到解决方案的工作方式印象深刻。一个好的开发团队将它们视为功能的基础，而不是功能规范。