做设计模式扼杀创造力

许多年前，我曾与经济学教授讨论设计模式，如何为程序员建立通用语言以及如何以良好的方式解决众所周知的问题等。

然后，他对我说，这与他的经济学学生所用的方法完全相反。他通常会提出一个问题，并要求他们首先找到解决方案，因此他们可以先考虑一下，然后尝试找到首先解决问题的方法，然后才提出“经典”解决方案。

所以我在想，“设计模式”方法是否真的会使程序员变得更聪明或更笨拙，因为他们很多时候只是获得“针对此问题的正确解决方案”，而不是利用创造力和想象力来解决某个问题。创新的方式。

你怎么看？

您的经济学教授是绝对正确的。

软件设计模式主要是有经验的软件开发人员相互交流的一种方式。它们是针对已知问题的既定解决方案的简写。

但是，只有那些了解如何在没有模式的情况下解决问题的人，或者自己想出类似模式的人才能使用它们。否则，它们将具有与复制/粘贴编码器相同的问题；他们将拥有代码，但是他们不了解其工作原理，因此将无法对其进行故障排除。

同样，许多设计模式都是企业模式，这些模式旨在用于大型公司软件系统中。 如果您了解了Inversion of Control容器的奇妙之处，您将希望在编写的每个程序中都使用它，即使大多数程序实际上并不需要它（有更好的方法将依赖项注入较小的程序中， （不需要IoC容器）。

学习模式。了解模式及其适当的用法。知道如何在没有模式的情况下解决相同的问题（所有软件模式都是对基本算法的抽象）。这样一来，您便可以放心使用软件模式。

设计模式人们希望您查看“设计模式”的方式是一套解决方案，如果出现类似问题，您可以应用这些解决方案。他们不希望您认为它们是上帝给山上刻在石碑上的摩西的唯一可能解决方案。

不幸的是，有些人将它们视为更接近圣旨，而不是可以从中学习的一堆示例设计。那确实杀死了创造力，并建立了一个狂热的崇拜者。

您的经济学教授提到向学生展示问题并让他们首先尝试解决问题，这是一种很好的教育技术，但他确实有解决方案可以向他们展示。拥有一堆解决许多不同问题的解决方案是一件好事，这是Design Patterns想要做到的。我认为它在某些方面会失败（Singleton鼓励使用错误的方法，对命令式OO进行近视检查等），但是可以很好地结合智能和品味使用。但是，认为软件中的所有可能示例解决方案都必须是官方设计模式是错误的。

如果您发现问题并问自己“这是什么设计模式？”，那么您做错了，那么您将不太可能看到面对您的解决方案。

如果您看到一个问题并问自己“我该如何解决？”，那么如果有一个非模式的解决方案，您将看到它，并且如果有一个合适的模式，您也会看到它。

我也认为您的经济学教授是正确的，这是一开始学习任何东西的方式。但是，让我们这样看：为了创造力，您是否会保守Wheel的秘密并让所有人重新发明它？我希望您说不，因为并非所有人都具有发明轮子的能力/能够发明轮子的能力-如果他们是，他们会在某个时候做到这一点，无论他们是否知道轮子的存在或不。

让我们回到程序员那里。我每天都是网络开发人员，因此MVC是我每天与之互动的事物之一。几次尝试构建自己的结构，我学到了很多东西，但是所有这些基本上都不成功。我已经尽力了，但是如果没有MVC会发生什么呢？好吧，简单，我的源代码很烂-就可靠性，可维护性和可扩展性而言。

我认为对于我们大多数人来说都是一样的。如果没有人告诉您有关DI的信息-作为一种好习惯，那么在开发人员吸取教训之前，有多少个企业应用程序应该挣扎或失败？

第二点是行业标准。如果您不向Web开发人员讲授MVC，那么您准备好面对所有那些非标准的结构，您需要花一些时间来首先学习它们的做事方式，然后您会意识到其中的一些结构可能会有一个好主意，但是其中大多数都会有严重的设计缺陷，这可能会对您的软件项目造成严重的后果-即使是众所周知的框架仍会不时地遇到设计缺陷。

但是，如果我们确实拥有所有这些好主意并将它们融合在一起，并且那些聪明的开发人员从所有这些实验中汲取了好东西，并形成了一个最酷的结构，该结构最适合该特定问题，将会发生什么？然后，您刚刚创建了设计模式。如果您是活物，那么别无选择。甚至动物在日常生活中也遵循最佳实践和设计模式。

不要重造锤子，但不要像钉子一样对待每个问题

编程模式可以节省大量时间，因为它们为您提供了现成的解决方案，经过了很好的文档记录和测试，并带有您容易忘记的典型案例。但是您需要学习（并思考）何时使用它们。

解释一下您的问题：学习驾驶会让我走得更快还是走得更慢？

学习如何使用编程模式并不意味着您不应该练习寻找自己的解决方案。仍然会有足够的问题来发挥您的创造力。知道编程模式只会让您快速解决众所周知的问题，并专注于那些不那么琐碎的问题。

回到问题的第二部分-教授对吗？

是的，他是对的。学习的主要目的是学习学生的思考。他们需要尝试找到自己的问题解决方案，然后再面对现有的解决方案。只有这样，他们才能真正理解它们。如果您首先学习它们的模式，则冒着风险，他们只会机械地学习以应用它们，而不是了解其背后的内容。

这就是您首先教学生编程的原因，并且在以后的学期中将介绍这些模式。

我绝对不建议通过教授设计模式来教编程。如果您不理解它们背后的原理，就无法很好地应用它们，因此教授这些原理就变得更加重要。

我倾向于认为，无论如何，设计模式对于工作的程序员而言也并非真正有价值。如果您完全了解给定设计模式所涉及的原理，那么在一个好的解决方案的情况下，您自然会倾向于自然而然地构造它（或类似的东西），即使您不知道这是一个带有名称的模式。无论您花什么时间学习模式，总的来说，最好花时间学习如何思考代码。如果您的“一般问题解决”技能没有达到标准，那么无论您在应用某些模式方面有多出色，您都无法编写好的代码。而且，如果您的“一般问题解决”技能很好，那么即使您不知道一个单一的模式，也可以解决问题。

我还认为，在理想的世界中不会有任何设计模式，因为足以被称为模式的通用想法都可以在库中很好地实现，并且我们实际上是在重复使用代码，而不是不断地重写它。想象一下，如果有一个“正则表达式设计模式”，那就需要您每次使用它时都实现一个小的正则表达式引擎。设计模式只是无法编写的库，因为该语言没有提供正确的抽象工具。

这实际上是不十分在乎它们的另一个原因。它们并不像有时所声称的那样普遍，但是实际上与特定语言允许/鼓励的结构化程序的特定方式紧密联系在一起。为Python编写的设计模式书与为Java编写的书完全不同，甚至与为非强制性语言（如Haskell）编写的书完全不同。更好地理解更深层次，并且您将能够使用任何熟悉的语言自己发现设计模式。

商业和教育有不同的目标。如果我要教学生设计模式，我会采用相同的方法。但是在生产环境中，时间和效率至关重要。

而且，课堂外的（宏观）经济学是另一回事。您是否看到政府在说：“哇！现在我们对税收非常无聊，而且还是以同样的方式进行，所以这次让我们尝试一些超级古怪的东西”？不，您不需要，因为如此疯狂的实验会破坏经济，使其无法修复。相反，他们倾向于坚持尝试和检验的方法：提高利率，宣布免税期等。换句话说，他们依赖设计模式。

答案是：当然可以。

设计模式本身就是一种很好的学习工具，只要人们花时间弄清楚它们是如何工作的以及它们为什么带来所带来的价值。

通过快速跟踪设计过程，它们还可以极大地提高生产力，因为它们为不断出现的问题提供了熟悉的解决方案。

但是，如果它们将设计短路得太多，或者人们对它们的使用变得教条式和过度精确，那么它们的作用相反。

设计模式当然没有创意。这就是整个想法。创造力是一种稀缺资源。您不应将其浪费在不需要创造力的问题上。如果您以与之前成百上千的开发人员相同的方式解决问题，这将更容易，更快捷且更有可能工作。发挥作用的乏味，令人兴奋的代码实际上是好的。