很多人似乎都同意，单例模式有许多缺点，有些人甚至建议完全避免这种模式。有一个excellent discussion here。请将有关单例模式的任何 cmets 指向该问题。
我的问题：是否还有其他设计模式应该避免或谨慎使用？
【问题讨论】：
标签： design-patterns anti-patterns
应谨慎使用所有设计模式。在我看来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 中描述的原则非常有用。
让那些沉没在你身上一段时间。应该注意的是，在编写 GoF 时，interface 表示任何抽象（也表示超类），不要与作为 Java 或 C# 类型的接口混淆。第二个原则来自观察到的过度使用继承，即sadly still common today。
从那里您可以阅读由 Robert Cecil Martin (aka. Uncle Bob) 公开的 SOLID principles。 Scott Hanselman 在podcast about these principles 采访了鲍勃叔叔：
这些原则是阅读和与同行讨论的良好开端。您可能会发现这些原则相互交织，并与separation of concerns 和dependency injection 等其他流程交织在一起。在做了一段时间TDD 之后，您可能还会发现这些原则在实践中很自然，因为您需要在一定程度上遵循它们才能创建 isolated 和 repeatable 单元测试。
【讨论】：
设计模式的作者自己最担心的是“访客”模式。
这是一种“必要的邪恶”——但经常被过度使用，而且对它的需求通常会揭示你设计中更根本的缺陷。
“Visitor”模式的另一个名称是“Multi-dispatch”，因为当您希望使用单一类型的调度 OO 语言根据两个（或更多）不同对象的类型。
典型的例子是两个形状之间有交集，但还有一个更简单但经常被忽视的例子：比较两个异构对象的相等性。
不管怎样，你经常会得到这样的结果：
interface IShape
{
double intersectWith(Triangle t);
double intersectWith(Rectangle r);
double intersectWith(Circle c);
}
这样做的问题是您已经将“IShape”的所有实现耦合在一起。您已经暗示，每当您希望向层次结构添加新形状时，您也需要更改所有其他“形状”实现。
有时，这是正确的最小设计 - 但请仔细考虑。您的设计是否真的要求您需要分派两种类型？你愿意写出多方法的组合爆炸吗？
通常，通过引入另一个概念，您可以减少实际需要编写的组合数量：
interface IShape
{
Area getArea();
}
class Area
{
public double intersectWith(Area otherArea);
...
}
当然，这取决于 - 有时您确实需要编写代码来处理所有这些不同的情况 - 但在尝试使用 Visitor 之前，值得暂停一下并考虑一下。它可能会在以后为您节省很多痛苦。
【讨论】：
单例 - 一个使用单例 X 的类对它有一个难以看到且难以隔离以进行测试的依赖项。
它们经常被使用，因为它们方便且易于理解，但它们确实会使测试变得复杂。
【讨论】：
我认为模板方法模式通常是一种非常危险的模式。
【讨论】：
我认为您不应该避免使用设计模式 (DP)，而且我认为您不应该在规划架构时强迫自己使用 DP。我们应该只在我们的计划中自然出现时才使用 DP。
如果我们从一开始就定义要使用给定的 DP，我们未来的许多设计决策都会受到该选择的影响，但不能保证我们选择的 DP 适合我们的需求。
我们也不应该做的一件事是将 DP 视为不可变的实体，我们应该使模式适应我们的需求。
所以，总而言之，我认为我们不应该避免 DP，我们应该在它们已经在我们的架构中形成时接受它们。
【讨论】：
我认为 Active Record 是一种过度使用的模式，它鼓励将业务逻辑与持久性代码混合在一起。它不能很好地从模型层隐藏存储实现并将模型与数据库联系起来。有很多替代方案（在 PoEAA 中描述），例如 Table Data Gateway、Row Data Gateway 和 Data Mapper，它们通常提供更好的解决方案，并且肯定有助于提供更好的存储抽象。此外，您的模型不应需要存储在数据库中；将它们存储为 XML 或使用 Web 服务访问它们怎么样？更改模型的存储机制有多容易？
也就是说，Active Record 并不总是很糟糕，并且非常适合其他选项过于繁琐的简单应用程序。
【讨论】：
这很简单...避免使用不清楚或您不喜欢的设计模式。
举个例子……
有一些不实用的模式，例如：
InterpreterFlyweight还有一些较难掌握，例如：
Abstract Factory - 具有创建对象系列的完整抽象工厂模式并不像看起来那么容易Bridge - 如果抽象和实现被划分为子树，可能会变得过于抽象，但在某些情况下是非常有用的模式Visitor - 双重调度机制的理解确实是必须的还有一些模式看起来非常简单，但由于与其原理或实现相关的各种原因，并不是那么明确的选择：
Singleton - 并不是完全糟糕的模式，只是被过度使用（经常出现在不适合的地方）Observer - 很棒的模式...只是让代码更难阅读和调试Prototype - 交换编译器检查的动态性（这可能是好是坏......取决于）Chain of responsibility - 经常被强行/人为地推入设计中对于那些“不切实际的”，在使用它们之前应该真正考虑一下，因为通常在某个地方有更优雅的解决方案。
对于“较难掌握”的……它们真的很有帮助，当它们被用在合适的地方并且被很好地实施时……但当它们使用不当时，它们就是噩梦。
现在，接下来是什么......
【讨论】：
我希望我不会因此而受到太多打击。 Christer Ericsson 在他的real time collision detection blog 中写了两篇关于设计模式主题的文章（one、two）。他的语气相当刺耳，也许有点挑衅，但这个人知道他的本事，所以我不会认为这是疯子的胡言乱语。
【讨论】：
有人说service locator是一种反模式。
【讨论】：
我相信观察者模式有很多要解决的问题，它适用于非常普遍的情况，但随着系统变得越来越复杂，它变成了一场噩梦，需要 OnBefore()、OnAfter() 通知，并且经常将异步任务发布到避免再次进入。一个更好的解决方案是开发一个自动依赖分析系统，在计算期间检测所有对象访问（带有读取障碍）并自动在依赖图中创建一条边。
【讨论】：
对 Spoike 的帖子的补充，Refactoring to Patterns 是一本不错的读物。
【讨论】：
迭代器是另一种要避免的 GoF 模式，或者至少只有在没有替代方案可用时才使用它。
替代方案是：
for-each 循环。这种结构存在于大多数主流语言中，并且在大多数情况下可用于避免迭代器。
选择器 à la LINQ 或 jQuery。当 for-each 不合适时应该使用它们，因为并非容器中的所有对象都应该被处理。与迭代器不同，选择器允许在一个地方显示要处理的对象类型。
【讨论】：
yield 迭代器实现的。 Eric White 在 C# 3.0 中对此进行了很好的讨论：blogs.msdn.com/b/ericwhite/archive/2006/10/04/…。另外，请查看 Jeremy Likness 对带有迭代器的协程的讨论：wintellect.com/CS/blogs/jlikness/archive/2010/03/23/…。