design-patterns - 应避免的设计模式

Question

就目前情况而言，这个问题不太适合我们的问答形式。我们希望答案得到事实、引用资料或专业知识的支持，但这个问题可能会引发辩论、争论、民意调查或扩展讨论。如果您觉得这个问题可以改进并可能重新开放， visit the help center以获得指导。

已关闭 11 年前。

很多人似乎都同意单例模式有许多缺点，有些人甚至建议完全避免该模式。有一个excellent discussion here 。请将有关单例模式的任何评论直接指向该问题。

我的问题:是否还有其他应该避免或谨慎使用的设计模式？

Answer 1

模式很复杂

所有设计模式都应谨慎使用。在我看来you should refactor towards patterns当有充分的理由这样做时，而不是立即实现模式。使用模式的普遍问题是它们增加了复杂性。过度使用模式会使给定的应用程序或系统进一步开发和维护变得很麻烦。

大多数时候，有一个简单的解决方案，您不需要应用任何特定的模式。一个好的经验法则是，每当代码片段倾向于被替换或需要经常更改时，就使用模式，并准备好在使用模式时接受复杂代码的警告。

请记住your goal should be simplicity如果您发现实际需要支持代码更改，请采用一种模式。

模式原则

如果模式明显会导致过度设计和复杂的解决方案，那么使用模式似乎毫无意义。然而，对于程序员来说，阅读为大多数模式奠定基础的设计技术和原则会更有趣。事实上我的一个 favorite books on 'design patterns' stresses this重申哪些原则适用于所讨论的模式。就相关性而言，它们足够简单，比模式更有用。有些原则足够通用，不仅仅涵盖面向对象编程 (OOP)，例如 Liskov Substitution Principle ，只要您可以构建代码模块。

除了first chapter of GoF book中描述的设计原则之外，还有很多设计原则。开始时非常有用。

• 针对“接口(interface)”而非“实现”进行编程。(Gang of Four 1995:18)
• 优先考虑“对象组合”而不是“类继承”。(Gang of Four 1995:20)

让这些内容深入你的脑海一段时间。需要注意的是GoF写的时候是interface表示任何抽象(也表示父类(super class))，不要与 Java 或 C# 中作为类型的接口(interface)混淆。第二个原则来自观察到的继承的过度使用，即 sadly still common today .

从那里您可以阅读 SOLID principles罗伯特·塞西尔·马丁 (Robert Cecil Martin) 公布了这一消息 (aka. Uncle Bob) 。斯科特·汉塞尔曼 (Scott Hanselman) 在 podcast about these principles 中采访了鲍勃叔叔:

• 单一责任原则
• 开放闭笔原则
• 李伊斯科夫替换原理
• 接口(interface)接口(interface)隔离原则
• D依赖倒置原则

这些原则是阅读并与同行讨论的良好开端。您可能会发现这些原则彼此交织并与其他流程交织在一起，例如 separation of concerns和 dependency injection 。做完后TDD有一段时间，您可能还会发现这些原则在实践中自然而然地出现，因为您需要在某种程度上遵循它们才能创建隔离和可重复单元测试。