设计模式到底有多重要？ [关闭]答案

【问题标题】：How important are Design Patterns really? [closed]设计模式到底有多重要？ [关闭]
【发布时间】：2019-12-29 15:57:45
【问题描述】：

设计模式到底有多重要？

我认为早期的程序员并没有那么多使用设计模式（80 年代和 90 年代中期之前毕业的人）。应届毕业生是否普遍了解并更多地使用它？

【问题讨论】：

您能发布您的调查结果吗？我对结果感兴趣
考虑到标签“design-patterns”已被用于关于 SO 的近 1000 个问题，我认为仅此一项就可以回答您的问题......或者至少其中一个问题可以回答。
@Kwang 我肯定会发布一些结果。有没有办法打开结果呢？如果可能的话，我想打开它。
当然80、90年代的人使用设计模式，但更重要的是人们在发明SmallTalk和CLOS之后开始使用它们。每个人都使用设计模式，只是大多数人没有意识到，因为他们不了解它们。你吃过汉堡吗？一片面包，一些肉，一些奶酪，一些沙拉，还有一片面包？那是设计模式！吃看起来像这样的东西有多难：一片奶酪，一片面包，沙拉，一片面包？
能否请您重新发布结果（作为文本中的图像）？我得到了 404。谢谢 :)

标签： design-patterns

【解决方案1】：

我们在 80 年代使用了设计模式，只是我们不知道它们是设计模式。

【讨论】：

设计模式在很大程度上适用于 OOP 是真的吗？在面向对象编程之前，它曾经是程序只是一系列指令或函数。但也许回调有点像观察者和委托的模式。而 90 年代的 Windows 编程基于事件循环和观察者的设计模式，即使不使用 OOP。

【解决方案2】：

在我看来，设计模式的最大好处是它为开发人员提供了一个通用的词汇来讨论软件解决方案。

如果我说，“我们应该使用单例模式来实现它”，我们有一个共同的参考点来开始讨论这是否是一个好主意，而无需我先实际实现解决方案，这样你就知道我在做什么了意思是。

增加常见问题的熟悉解决方案带来的可读性和可维护性，而不是每个开发人员都试图以自己的方式重新解决问题。

非常重要。没有它们也可以制作软件，但肯定要困难得多。

【讨论】：

所以现在我们让每个开发人员都尝试用同样的几种方式解决问题，无论它们是否合适。您提出的 Singleton 示例说明了这一点 - 我怀疑仅模式造成的糟糕设计比所有明确命名的设计模式加起来造成的良好设计还要多。
但是你不高兴你可以告诉人们不要以某些方式使用单例模式，而且他们知道你在说什么。
Singleton 模式在很多情况下可能使用不佳，但考虑到大多数人使用不佳的替代方案将是大量的全局变量，我认为这很难怪设计单例模式的存在。
并不是那么难——我认为人们会更不愿意使用全局变量，因为这些变量长期以来被认为是一件坏事——但是对于 Singleton，它有一个名字并且是一个完全认可的 GoF 设计模式似乎让人忘记了它基本上只是对全局变量的伪装。
@Michael 没有防止愚蠢的安全措施。如果你误解了圣经，这不是圣经的错，就像宗教一样，没有人强迫你（圣经）模式。

【解决方案3】：

它们不是绝对需要的，但好处肯定大于坏处。

好的：

代码可读性：它们确实可以帮助您编写更易于理解的代码，并为您要完成的任务提供更好的名称。
- 代码可维护性：让您的代码更易于维护，因为它更易于理解。
- 沟通：它们帮助您在程序员之间沟通设计目标。
- 意图：它们会立即向学习代码的人显示代码的意图。
- 代码重用：它们可以帮助您确定常见问题的常见解决方案。
- 更少的代码：它们允许您编写更少的代码，因为您的更多代码可以从通用基类派生通用功能。
- 经过测试且可靠的解决方案：大多数设计模式都经过测试、验证且可靠。

坏处：

额外的间接级别：它们提供额外的间接级别，因此使代码更复杂一些。
- 知道何时使用它们：它们经常被滥用并在不应该使用的情况下使用。一项简单的任务可能不需要使用设计模式来解决的额外工作。
- 不同的解释：人们有时对设计模式的解释略有不同。 django 看到的示例 MVC 与 Ruby on Rails 看到的 MVC。
- 单身人士：需要我多说吗？

【讨论】：

我完全同意，但您的批评 (1) 似乎适用于特定模式而不是设计模式概念。尽管最常见的设计模式都是基于间接级别的。
当您添加“Singleton”时，我不得不笑。多年来，它一直是我的眼中钉！！！
:) 我添加它主要是为了幽默，但全局状态和将自己限制在某件事上无论如何都不是一件好事。
很好的概述。我只不同意“坏”的第二点。很明显，您在使用它们时需要了解它们。好比说java抽象类不好，因为你需要知道怎么用。

【解决方案4】：

就我个人而言，我认为它们被过度炒作且价值微乎其微。这个想法听起来很棒，但当你真正开始使用它时，真的只有少数几个常见且有用到值得记住（并且可能记住）。

我想说它们的净效应是负面的，因为新近迷恋这个概念并试图将尽可能多的模式塞进他们的代码中的人们进行了可怕的过度工程。也许更糟糕的是Maslow's hammer 效应会导致糟糕的设计，因为开发人员没有找到最佳的，而是记住了一种适合（严重）的设计模式。

【讨论】：

人们是否进行判断或追随与设计模式是否被过度炒作和是否具有边际价值是正交的。编程的第一条规则是：“思考”。是否有人将该规则替换为“使用设计模式”，这与设计模式在适当位置使用时的效用完全无关。
Justice，很抱歉，但您似乎没有遇到那种喝设计模式 kool-aid 的人，他们的代码已成为您的维护噩梦。设计模式本身在正确的人手中可能还不错，但就像一个有问题的编程语言功能一样，它们会招致滥用，因此本身就值得怀疑。
不是正交的——正是 IMO 的炒作（以及“好主意”的诱惑）导致人们用“使用设计模式”代替他们的个案判断。我的部分观点是，虽然“正确使用”设计模式是有益的，但好处并没有超过广泛的滥用。

【解决方案5】：

我见过太多“有图案的小男孩”综合症的案例。通常在一个人第一次阅读 GoF 的书之后，它就会受到最强烈的打击，并立即跑去看看他们有多少人可以适应他们正在从事的项目。（将所有 23 个项目塞进一个项目的额外积分。）他们最终得到了一个在其生命周期内设计的系统，并且无法理解或修改。

最终，发烧停止了，他们安定下来，可以适当地使用它们。但伤害可能很大。

警示故事是“核心 Java EE 模式”一书。它列出了一堆解决 EJB 1.0 和 2.0 的“最佳实践”的东西，这些东西现在被认为是反模式。 EJB 3.0 规范取消了很多。春天正在扼杀其余的一切。

模式在阳光下度过了美好的一天，例如 UML。但是太阳正在下山。我认为没有一个人拯救了世界，也没有在炒作中实现。

【讨论】：

【解决方案6】：

虽然有时谈论设计模式很有用，但我倾向于同意那些认为它们在许多情况下有害的人的观点。

我要提出的主要论点是，它们实际上通常会阻止人们针对特定问题提出适当的解决方案。人们没有考虑如何解决这个特定问题，而是尝试一个接一个地应用一种设计模式。

他们还倾向于隐藏语言缺陷。它们中的很多在足够表达的语言中都是微不足道的。一个典型的例子是策略模式，它基本上以一种复杂的方式重新发明了函数式编程。通常人们最好理解真正的编程原理，而不是仅仅谈论模式语言。

话虽如此：我宁愿与某人谈论模式，也不愿完全没有共同语言。这样，如果没有更好的选择，它们就很重要。如果我可以用更正式的方式（例如代数）来解释自己，那么我就不再关心模式语言了。当然，有些人会声称我只是用这种方式发明了自己的模式语言；-)

【讨论】：

【解决方案7】：

我认为你错过了设计模式是什么的重点。

在软件工程中，设计模式是针对软件设计中常见问题的通用可重用解决方案。

所以设计模式只是定义解决软件工程问题的常用方法的正式语言。我认为大多数人都在使用设计模式而不知道他们是。所以这些软件问题的常见解决方案可以追溯到很久以前，他们只是没有提出一种正式的语言来描述他们在做什么。

我认为设计模式很重要，因为它们教会了你解决设计模式应用领域中问题的命令方法。

【讨论】：

【解决方案8】：

我不会用“重要”这个词。我会用“有帮助”这个词。为开发人员提供一种通用语言来描述常见问题/解决方案很有用——在协作环境中更是如此。

【讨论】：

【解决方案9】：

我发现设计模式具有边际价值。任何组织良好且设计良好的软件框架都有数百种设计模式，在正式的“模式文献”中描述的很少。

在设计模式出现之前，有设计良好的软件，其中有许多可以在许多情况下重用的模式。例如，Kernighan 和 Ritchie 关于 C 的书包含一个使用 yacc 和 lex 以及堆栈、符号表、函数指针传递（即基本上是动态绑定）实现的计算器示例，并包含大量适合书本大小的模式。

您可能可以通过学习例如学习数百种更有用的设计模式Microsoft 的 .NET 框架、Java 类库等比通过阅读有关设计模式的书。

确实，好的软件都有设计。如果设计好，它可能可以重复使用。瞧——一种设计模式。

【讨论】：

【解决方案10】：

我会说它们肯定很重要。

在典型的原因（共享词汇，而不是重新发明轮子）中，它们是学习优秀软件设计的垫脚石。大多数设计模式都是由对 OO 原则有很好理解的程序员开始应用他们所知道的来解决问题的，并注意到其他人正在提出相同的解决方案。如果您将设计模式视为解决当前遇到的问题的食谱，那么它们并不是真正有用，而这正是您看到“设计模式锤”出现并使设计复杂化的地方。

如果将其视为了解良好的面向对象设计的窗口，您就会开始看到它们的价值，即考虑设计模式背后的原则，而不是具体的设计模式本身。

【讨论】：

【解决方案11】：

我会说非常

设计模式的诀窍是了解何时何地使用它们。然后可以为你做各种喜欢的事情：

让您的代码更具可读性
易于维护
使其更灵活
不胜枚举...

但有时他们可以做与某些好处完全相反的事情，因为他们知道如何以及何时......

你有没有试过用框架锤拉出条子？你可能喜欢你的框架锤，但如果你尝试这样使用它会导致各种各样的问题......

我认为当你重构你的代码时，它有时会演变成一个特定的模式，或者你可能一直在使用一个模式而没有意识到它。

【讨论】：

根据我的经验，有意识地考虑设计模式的开发人员会更频繁地实现相反的效果。
我同意...我会说编写代码...然后在可能和必要时重构，就像我说的设计模式可能会发展。但有时在设计过程中，您可能也会看到使用其中一个的机会。

【解决方案12】：

好问题！大约一周前，我只是在问自己这个问题。我尽可能地使用它们，但我并没有找到很多使用它们的机会。我个人认为设计模式的想法很棒。机械工程师和电子工程师不会从头开始设计，而是应用易于理解的模式，让新手能够站在前人所掌握的知识的肩膀上。设计模式是朝着正确方向迈出的一步，但还需要更多的步骤。

【讨论】：

【解决方案13】：

在考虑模式之前先从原则开始，因为它是指导和激发模式出现的总体设计原则。

对于您的特定问题，最好首先遵循以下原则。如果你到达了一个众所周知的模式，那么恭喜你，你刚刚重新发现了一个模式，对你有好处。问题是这可能会花费你很长时间，所以这取决于你是想冒险发明一些反模式，还是想为已经发布的东西找到捷径。不过考虑一下，因为你会学到比阅读别人对自己工作的描述更多的东西。

不利的一面（正如这里的许多非常好的答案已经指出的那样）是您可能会在不适合或没有保证的情况下应用已发布的模式。

从设计原则入手的一个好地方是查看Uncle Bob Martin's SOLID principles，它们的好处是，一旦他们深入了解它们，你会觉得你已经了解它们（这让你感觉很聪明）并且

Bob 叔叔的书Clean Code 也涵盖了许多相同的原理和一些有用的示例，只是没有像原始文章那样明确引用这些原理，而是更侧重于一般组织和整理您的函数、类等。

【讨论】：

【解决方案14】：

软件模式很重要，无论您是否知道自己正在使用它们……根据定义。

设计模式只是针对常见问题的一种通用的、可重用的解决方案。

您可以四处寻找，直到重新发明解决您遇到的每个问题的方法，或者您可以学习程序员几代人一直在使用的“模式”。如果您将最常见的命名模式的知识形式化，您将有一个共同的词汇来讨论和应用解决方案。

【讨论】：

【解决方案15】：

设计模式在 CS 的设计课程中教授。它们不是必需的，但如果您能找到类似的情况来制定经过深思熟虑的解决方案，它们会非常有用。

它还允许程序员更轻松地进行交流。您也可以就模式与您的同事交谈。如果你在这里说我有我的观察者，那么就很清楚发生了什么。

人们自然会想出适合自己的设计模式的解决方案，但设计模式有助于定义有用的术语和标准想法。

这些模式并没有什么特别之处，最好的一点是它们是经过规范化和定义的想法，可以反复使用。

【讨论】：

【解决方案16】：

如果您尝试为开源项目做出贡献，评论的设计模式会很有帮助......说得够多了！

【讨论】：