设计模式真的有多重要？

Question

设计模式真的有多重要？

我认为前一代程序员并没有那么多使用设计模式（那些在80年代和90年代中期毕业的人）。最近的毕业生是否一般都知道并使用它更多？

如果你有兴趣，我也做了一件事，你可以在这里查看：

http://www.surveymonkey.com/s.aspx?sm=kJOdGX0RPx5FGrfPVm_2bmIw_3d_3d

更新：以下是初步调查结果：

http://img192.imageshack.us/img192/7107/surveyresults.png

Answer 1

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

Answer 2

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

如果我说“我们应该使用单例模式实现这一点”，我们有一个共同的参考点，开始讨论这是否是一个好主意，而我不必先实际解决这个问题所以你知道我是什么意思。

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

非常重要。可以在没有它们的情况下制作软件，但这肯定要困难得多。

Answer 3

它们并非绝对需要，但好处肯定超过了坏处。

好处：

1. 代码可读性：它们可以帮助您编写更易理解的代码，并为您要完成的工作创建更好的名称。
   • 代码可维护性：允许您的代码更容易维护，因为它更容易理解。
   • 沟通：它们可以帮助您在程序员之间传达设计目标。
   • 意图：他们会立即向学习代码的人展示您的代码的意图。
   • 代码重复使用：它们可帮助您确定常见问题的常见解决方案。
   • 更少的代码：它们允许您编写更少的代码，因为更多代码可以从公共基类派生常用功能。
   • 经过测试和完善的解决方案：大多数设计模式都经过测试，验证和完善。

---

糟糕：

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

Answer 4

就个人而言，我认为他们极度过分且边际价值。这个想法听起来很棒，但是当你开始讨论它时，实际上只有少数几个常见且有用的东西值得记住（并且可能记住）。

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

Answer 5

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

  

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

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

我认为设计模式很重要，因为它们教你如何解决设计模式适用的领域中的问题。

Answer 6

我见过太多“小男孩有模式”综合症。在一个人第一次阅读GoF书籍之后，它通常会受到最严重的打击，并立即跑掉，看看他们中有多少人可以融入他们正在进行的项目中。 （将所有23个填入单个项目的额外要点。）他们最终得到的系统设计在其生命的一英寸范围内，无法理解或修改。

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

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

模式在阳光下度过了一天，就像UML一样。但太阳正在下降。我认为，任何一个人都没有拯救世界，也没有宣传过。

Answer 7

重要的不是我会用的词。我会用“有帮助”这个词。为开发人员提供用于描述频繁问题/解决方案的通用语言非常有用 - 而且在协作环境中也是如此。

Answer 8

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

我要提出的主要论点是，它们通常会阻止人们针对特定问题提出适当的解决方案。人们尝试将一种设计模式应用于另一种设计模式，而不是考虑如何解决这一特定问题。

他们也倾向于隐藏语言缺陷。在语言表达方面，很多都是微不足道的。一个典型的例子是战略模式，它基本上以复杂的方式重塑功能编程。通常人们会更好地理解真正的编程原则，而不仅仅是谈论模式语言。

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

Answer 9

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

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

通过研究，您可以学习数百种更有用的设计模式。微软的.NET框架，Java类库等比通过阅读有关设计模式的书籍。

真的，好的软件有一个设计。如果设计很好，它可能会被重复使用。 Voila - 一种设计模式。

Answer 10

我会说非常

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

1. 让您的代码更具可读性
2. 易于维护
3. 让它更灵活
4. 这个名单继续......

但有时他们可以做出与其中一些好处完全相反的事情，知道如何以及何时......

你有没有试过用框架锤拔出条子？你可能会爱你框架锤，但如果你试图用这种方式它会引起各种各样的问题...

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

Answer 11

我会说他们肯定很重要。

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

如果将其视为良好的面向对象设计的窗口，您就会开始看到它们的价值，即根据设计模式背后的原则而不是特定的设计模式本身进行思考。

Answer 12

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

Answer 13

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

设计模式只是针对常见问题的通用，可重复使用的解决方案。

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

享受，

Robert C. Cartaino

Answer 14

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

对于您的特定问题，您最好遵循以下原则。如果你到达一个着名的模式那么，恭喜你，你刚刚重新发现了一个模式，对你有好处。问题在于它可能需要很长时间，所以这取决于你是否想冒险发明一些反模式，或者你是否想要快速发布已发布的内容。考虑一下，因为你不仅仅是阅读别人对自己工作的描述。

低端（这里已经指出的许多非常好的答案）是你可能想要在不适合或不保证的情况下应用已发布的模式。

从设计原则入手的一个好地方是看Uncle Bob Martin's SOLID principles，关于它们的好处，一旦它们陷入其中，就是你觉得你已经认识它们（这让你感觉很聪明）和< / p>

鲍勃叔叔的书Clean Code也涵盖了很多相同的原则和一些有用的例子，只是没有明确地引用原始文章的原则，而是更多地集中于组织和整理你的函数，类等。

Answer 15

设计模式在CS的设计类中讲授。它们不是必不可少的，但如果你能找到类似的情况来获得经过深思熟虑的解决方案，那么它们就非常有用。

它还允许程序员更轻松地进行通信。您也可以根据模式与您的同事交谈。如果你在这里说我有我的观察者，那么很清楚它是怎么回事。

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

这些模式没什么特别值得注意的，最好的是它们是经典的，并以反复有用的方式定义。

Answer 16

评论说，如果您尝试为开源项目做贡献，设计模式会很有用......足够说了！