设计模式通常是造就好坏的力量吗？[关闭]
Answers:
设计模式是一种语言，不是建议编写程序或合同。它们的主要用途是事后解释，说明如何（或将要）实现组件或系统。您不必说太多细节，只需说几句话就可以很好地描述实现，以使侦听器可以了解它的工作原理以及其中的重要内容。
Alex：嘿，如何创建配置文件？
鲍勃：它们是由位于的工厂产生的
config.h。
现在，Alex知道配置文件的创建涉及不平凡的准备工作，因为否则它们的创建将不会包含在工厂中。
但是，如果Bob是一个以模式为首的假人，并且只在这里和那里使用过模式，那么Alex就无法告诉任何有关配置创建的信息，因为Bob到处都使用了factory。这也将导致程序过于复杂。
因此，首先编程，然后在代码中发现模式，反之亦然。这就是有效使用它们的方式。
如果正确使用设计模式，那就太好了。
记住设计模式的思想起源于建筑是很有用的。体系结构可以千差万别。但是，任何建筑物中都存在许多核心思想。这样，可以将模式视为设计的基础。重要的是要注意，并非每座建筑物都包含所有可能的建筑模式。
假设您正在设计房屋。与其将前门敞开在街道上，不如在进入房屋之前先要有一个庇护区，即一间休息室。该区域将适合某种模式。即，它将有两个入口，一些墙壁，可能还有一个屋顶。注意，该模式未指定门，窗或墙壁数。在大多数实现中，将有两个门，四个墙，可能还有窗户。但是，该模式描述了一个带有两个入口的封闭区域。一个人从房子外面通向前厅，另一个人进入房子的其余部分。这里的关键是，如果要使用前厅，则必须围成一个区域，并提供进入该区域的两个入口。
编程中设计模式的典型问题是过度使用，并且认为它们是解决任何问题的灵丹妙药。他们不是。它们是交流和思考有用的编程思想的方式。如果特定语言的语法部分是实体，则模式描述了一些有用的方式来安排它们以满足特定需求。
我认为设计模式更多是“ 建议 ”，而不是绝对必须遵循的不变合同。为什么？正是由于您提到的原因。在所有内容中遵循设计模式会导致大量的代码混乱，从而破坏了首先使用模式的目的。
这就是为什么我讨厌像Java Practices这样的网站。当然，有些想法是好的，但是作者决定按照他提到的每个设计模式编写一个完整的程序（加上一个框架）。作者还用可怕的引号写了每篇文章，使读者认为实际的Java实践是可怕的，应避免像瘟疫一样避免。
TL; DR：使用设计模式。只是不要虐待他们
也可以在SO上看到该线程。另一个POV设计模式是样板代码，以弥补所使用方法的不足。我不喜欢过分地庆祝这些解决方法。
我更喜欢那些在中间的人。就像海报正确指出的那样，对模式的理解并不能使您成为优秀的开发人员。另一方面，对模式的理解将帮助您成为一名优秀的开发人员。
了解模式的关系并在项目中（处于概念阶段）查看模式，这将使您成为一名优秀的开发人员。
人们常说设计模式为编程问题提供了现成的解决方案。他们是什么问题？“如何更改对象行为，但将更改与系统其余部分隔离开呢？”
GoF模式被认为可以提供与系统其余部分的隔离（封装），但是通常很难通过使用其设计模式来知道系统的哪个部分具有可变性。我没有遵循他们提出的分类方案（创造性的，行为的和结构的），而是绘制了模式的差异并提出了另外两种方案来对其模式进行分类：生命周期和组件封装层次结构。
从该表可以看到封装层次结构，设计模式可以应用于组件的每个级别。但这有意义吗？组件是否需要在建议的封装级别上提供行为变化，并且在该级别上使用了正确的模式吗？如果未正确回答这些问题，则很可能会错误地应用设计模式。仅仅因为可以在汽车机舱中内置垂直枢轴，这并不是一个聪明的主意。