什么时候设计模式会让你的软件变得更糟？
我看过一个程序，他们在 GUI 和逻辑之间使用外观模式。他们认为不能通过此传输任何对象，因此仅使用原始类型，这使得编码变得困难。
问问题
2715 次
18 回答
21
当你误用它时，或者有时更糟的是，当你不必要地使用模式时。后者让我发疯，因为当我分析一段代码时，我自然会首先假设其中的一切都是有原因的，而当我看不到某事的原因时，最安全的默认假设是我遗漏了一些东西。而且由于我不想冒险以未知或不可预测的方式破坏代码，所以我会浪费时间试图弄清楚为什么在我弄乱它之前就在那里。
于 2009-11-30T14:30:15.017 回答
17
几十年来，程序员经常花时间通过应用他们不理解的实践来使软件变得更糟，而不是学习为什么这种实践是好的。 某些工具/关键字/框架的使用可以让程序员感到复杂，当他们只是把事情搞砸时。一些常见的例子：
- 投入大量的 try/catch/finally 块可以让程序员觉得他们有一个错误处理方案，而实际上他们没有。
- 用存储过程替换 sql 可以让程序员觉得他们有一个数据访问层，神奇地赋予他们效率、可重用性和封装性，而实际上他们没有。
- 使用类使许多程序员相信他们正在从事面向对象的编程，而实际上他们并非如此（或者只是触及了面向对象的表面）。
这份清单可能会一直持续下去。这种趋势一直存在并且永远存在，因为我们人类总是在寻找捷径。我们现在在模式中看到了很多，因为模式目前很流行。根本问题是一样的：开发人员不尊重软件开发的复杂程度，认为盲目实施的模式或实践是学习和谦逊的替代品。
解决方案？很难说。尽管交给初级开发人员Code Complete或类似的东西，你不会出错，以帮助他们理解这就是将原则应用于特定情况，并且优秀的开发人员保持简单。
于 2009-11-30T16:25:21.843 回答
4
当它的名字是单例时
于 2009-11-30T14:36:01.737 回答
3
如果您滥用设计模式，将其应用在错误的情况下，它可能会使您的软件变得更糟。常识应该是设计模式的完美伴侣。
模式的滥用有时与缺乏对与问题相关的力量以及模式为该问题提出的解决方案的理解有关。此外，该模式的意图可能会被误解，从而导致误用。
为了更好地理解模式，您还需要了解反模式概念并阅读比 GOF 书籍更多的内容。一个建议是阅读Pattern Hatching来补充 GOF 的概念。
于 2009-11-30T14:39:33.140 回答
3
设计模式只是一种命名和记录通用代码结构的方法。因此，您不应断定所有模式都是好的模式。擅长记录设计模式（例如 GoF）的人总是在模式描述中包含一个部分，描述您何时应该和不应该使用该模式。因此，大多数设计模式书籍的一半目的是回答“设计模式什么时候会让你的软件变得更糟？”这个问题。
许多没有经验的开发人员从不费心去学习适当的使用部分，并最终在不合适的地方应用模式。我认为这是围绕设计模式产生很多负面影响的原因。
总之，这个问题的答案应该是：-去阅读设计模式，它会告诉你。
于 2009-11-30T15:20:46.317 回答
2
有趣的是，在过去的一年里，我投入了大量的时间来学习设计模式及其实现——就像对设计模式的反击似乎越来越多一样。无论是否公平，设计模式都加入了本应使软件成为可量化技能的流程和方法论的行列——即，使用它们会使您编写更好的代码的谬论。我认为设计模式的问题在于不太熟练的程序员将它们用作“金锤”。他们学习了策略模式——这是一件很有价值的东西——但随后他们到处使用它，使他们的代码过于复杂，并添加了不必要的特性和“可扩展性”。
我相信重构模式具有巨大的价值，因为您正在清理现有代码。模式也是有价值的交流工具，可以让你用更高层次的术语来描述你的代码。但是将设计模式填充到您的软件中，因为它们很酷且可销售（又名“简历驱动开发”）是一个坏主意。
于 2009-11-30T17:11:28.013 回答
1
什么使容易变得困难（EJB）
于 2009-11-30T14:48:06.580 回答
1
当您的问题出现错误的模式时。
于 2009-11-30T14:56:15.160 回答
1
一般来说，当编码人员认为模式是构建软件的乐高积木时，你会得到一些非常奇怪的代码。
于 2009-11-30T15:16:35.027 回答
1
当您将设计模式用作绝对的构建块而不是蓝图来帮助解决编码问题时，该软件会变得更糟。
它们并不意味着构成问题的块。它们不应该出现在对象命名约定中。对象不应称为 *Factory 或 *Singleton，或任何其他模式名称。它们不应该被锁定到特定的模式。
它们只是帮助人们更快地构建复杂代码的非常好的“起点”。您可以（并且应该）根据需要混合和匹配这些想法。文档？这就是评论的目的，而不是 Object 命名空间......
保罗。
于 2009-11-30T16:32:15.283 回答
1
它被称为反模式，示例请参考反模式：重构软件、架构和危机中的项目一书。
于 2010-03-30T12:07:06.447 回答
1
例如，您可以在此处阅读有关反模式的信息。
于 2010-03-30T12:15:10.487 回答
0
我认为如果不需要，策略模式会使软件变得更糟。策略模式基本上使一个功能“可插入”，这意味着我们可以动态切换不同的实现。但是这种可插拔的功能通常会增加配置的很多复杂性（有时还会增加额外的开销），如果不需要，那就是浪费。我看到这种模式经常被滥用。
于 2009-11-30T14:24:41.470 回答
0
Levi，如果它使我的生活（以及负责维护代码的人）更轻松，我只会使用特定的模式。我相信正确的设计模式选择和评论一样重要——也许评论更重要？您会发现设计模式在很大程度上正式描述了我们作为开发人员多年来一直使用的技术。
博学的穴居人
于 2009-11-30T14:36:48.793 回答
0
任何被误解或错误应用的模式都会使代码变得更糟而不是更好。此外，任何仅仅为了模式而应用的模式，例如“我们现在是 SOA！”。一般来说，如果一个模式引入了“代码气味”，那么它的使用应该是值得怀疑的。
于 2009-11-30T14:39:05.647 回答
0
我会说，每当您选择基于解决一个问题的模式时，而不是您的软件打算解决的所有问题。
相反，试图过度设计解决方案以适应所有可能的最终用例可能会导致您使用过于庞大而无法适应大多数用例的设计模式。
因此，理想的模式/坚持该模式的水平将介于两个极端之间。
于 2009-11-30T14:43:22.237 回答
0
我可以想到很多设计模式可能出错的方式。GoF 书解释了它所讨论的所有模式的问题、解决方案和缺点。- 模式是解决问题的方法。如果那个问题不是你的问题，那么它可能会变成一个反模式。- 模式有缺点，你应该意识到它们。- 当你不需要它时。一个模式可能意味着很多类，并且您正在尝试解决您将来可能遇到但还没有解决的问题。- 如果你不理解它是如何工作的并且你错误地实现了它，它也会变成一个反模式。你最终会得到很多无用的类和代码。- 当你开始上瘾的时候。层次结构太深、多态性或单例使用不当等都会造成问题。
应该还有其他原因……
于 2009-11-30T15:08:17.840 回答
0
当人们分析代码并花费更多时间试图理解模式而不是业务逻辑时。模式很好，但前提是每个参与的人都知道如何阅读它们。
于 2010-03-30T12:30:29.717 回答