设计模式何时会使您的软件变得更糟？

Question

何时设计模式会使您的软件变得更糟？

我见过一个程序，他们使用GUI和逻辑之间的Facade模式。他们认为没有任何对象可以通过它传输，所以只使用原始类型，这使得编码很困难。

Answer 1

当您滥用它时，或者有时更糟糕的是，当您不必要地使用模式时。后者让我疯狂，因为当我分析一段代码时，我自然首先假设那里有一切的原因，当我看不出某事的原因时，最安全的默认假设是我错过了一些东西。而且由于我不想以未知或不可预测的方式破坏代码的风险，我浪费时间试图弄清楚为什么它在那之前我惹它。

Answer 2

几十年来，程序员经常花时间通过应用他们不理解的实践来使更糟糕，而不是学习为什么这种做法是好的。使用某些工具/ keywords / frameworkes可以让程序员感觉很复杂，当他们只是搞砸了。一些常见的例子：

• 投入大量的try / catch / finally块会让程序员感觉他们有错误处理方案，而事实上他们没有。
• 用存储过程替换sql可以让程序员感觉他们有一个数据访问层，神奇地为他们提供了效率，可重用性，封装，而事实上他们没有。
• 使用类使许多程序员相信他们正在进行面向对象编程，而事实上他们并非（或者只是在OO的表面上）。

此列表可以永远持续下去。这种趋势一直存在并且永远存在，因为我们人类总是寻找捷径。我们现在看到了很多模式，因为模式目前很受欢迎。根本问题是相同的：开发人员不尊重软件开发的复杂程度，并且认为盲目实施的模式或实践可以替代学习和谦虚。

解决方案？很难说。虽然交给一个初级开发人员Code Complete或其他一些人来帮助他们理解这是关于将原则应用于特定情况，并且伟大的开发人员保持简单，但你不能犯错。

Answer 3

当它的名称是 singleton

时

Answer 4

如果您滥用设计模式可能会使您的软件变得更糟，在错误的情况下应用。常识应该是设计模式的完美伴侣。

模式的滥用有时与缺乏对与问题相关的力量的理解以及提出的解决该问题的模式相关联。此模式的意图也可能被误解而导致滥用。

为了更好地理解模式，您还需要了解Anti pattern概念并阅读比GOF书更多的内容。一个建议是阅读Pattern Hatching以补充GOF的概念。

Answer 5

设计模式只是一种命名和记录公共代码结构的方法。因此，您不应该断定所有模式都是好模式。做好记录设计模式的人（例如GoF）总是在模式描述中包含一个部分，描述何时应该而且不应该使用该模式。因此，大多数设计模式书籍的一半要点是回答“何时设计模式会使您的软件变得更糟？”这个问题。

许多缺乏经验的开发人员从不费心去学习适当的用途部分，最终应用不合适的模式。我认为这是围绕设计模式产生很多负面影响的原因。

总之，这个问题的答案应该是： - 去阅读设计模式，它会告诉你。

Answer 6

有趣的是，在过去的一年里，我花了相当多的时间学习设计模式及其实现 - 正如设计模式似乎有越来越多的反击。无论是否公平，设计模式都加入了应该使软件成为可量化技能的流程和方法的行列 - 即使用它们的谬误会让你编写更好的代码。我认为设计模式的问题在于，技能较低的程序员会将它们用作“金锤”。他们学习了战略模式 - 这是一件很有价值的事情 - 然后他们将无处不在，过度复杂化他们的代码并添加不必要的功能和“可扩展性”。

我相信重构对模式有巨大价值，因为您正在清理现有代码。模式也是有价值的沟通工具，可让您以更高级别的术语描述代码。但是将设计模式填充到你的软件中是因为它们很酷且可以销售（a.k.a“简历驱动开发”）是一个坏主意。

Answer 7

例如，您可以阅读有关反模式here的内容。

Answer 8

它被称为反模式，请参阅AntiPatterns：危机中的重构软件，架构和项目书籍。

Answer 9

简单易行的原因（EJB）

Answer 10

如果你的问题是错误的模式。

Answer 11

一般来说，当编码人员认为模式是类似lego的砖块时，人们就会构建软件，你会得到一些非常奇怪的代码。

Answer 12

当您使用设计模式作为绝对构建块而不是蓝图来帮助解决编码问题时，软件会变得更糟。

它们并不意味着构成问题的块。它们不应出现在Object命名约定中。不应将对象称为* Factory或* Singleton，或任何其他模式名称。它们不应该被锁定在特定的模式中。

它们是非常好的“起点”，可以帮助您更快地构建复杂的代码。您可以（并且应该）根据需要混合和匹配这些想法。文档？这就是评论的内容，而不是Object名称空间...

保罗。

Answer 13

当人们分析代码并花费更多时间来理解模式而不是业务逻辑时。模式是好的，但只有当涉及的每个人都知道如何阅读它们时。

Answer 14

我认为如果不需要，strategy pattern会使软件变得更糟。策略模式基本上使一部分功能“可插拔”，这意味着我们可以动态地切换出不同的实现。但是这种可插拔功能通常会增加配置的复杂性（有时会增加额外的开销），如果不需要，则会浪费。我看到这种模式经常被滥用。

Answer 15

我可以想到许多设计模式可能出错的方式。 GoF书解释了它所讨论的所有模式的问题，解决方案和缺点。 - 模式是问题的解决方案。如果这个问题不是你的问题，那么它可能会成为一个反模式。 - 模式有缺点，你应该知道它们。 - 当你不需要它时。一个模式可能意味着很多课程，而你正试图解决你将来可能遇到的问题，但还没有。 - 如果你不理解它是如何工作的并且你错误地实现它，那么它也会变成反模式。你最终会得到很多无用的类和代码。 - 当你开始沉迷于它。太深的层次结构，使用多向性或单例等等可能会造成问题。

可能还有其他原因......

Answer 16

我会说，无论何时选择基于解决一个问题的模式，而不是软件打算解决的所有问题。

相反，尝试过度设计解决方案以适应所有可能的最终用例可能会导致您使用过于庞大的设计模式以适应大多数用例。

因此，遵循该模式的理想模式/水平将介于两个极端之间。

Answer 17

任何被误解或误用的模式都会使代码变得更糟而不是更好。此外，任何仅为了图案而应用的图案，例如， “我们现在是SOA！” 通常，如果模式引入“code-smell”，那么它的使用应该是可疑的。

Answer 18

列维，   如果它让我的生活（以及负责维护代码的那些）更容易，我只会使用特定的模式。我认为正确的设计模式选择与评论同样重要 - 也许评论更重要？您会发现设计模式在很大程度上正式描述了我们作为开发人员多年来使用的技术。

TheEruditeTroglodyte