设计模式的伟大之处在于它们将一种潜在的复杂技术提炼成惯用的东西。通常只是它有一个名字就有助于沟通和理解。
缺点是它更容易尝试将它们用作灵丹妙药，将它们应用于每种情况而无需考虑其背后的动机，并花一秒钟时间考虑给定模式是否真的适合这种情况.
与this question 不同，我不是在寻找经常误用的设计模式，但我希望看到一些真正可靠的设计模式被滥用的例子。我正在寻找有人“错过了重点”并应用了错误的模式，甚至实施得很糟糕的情况。
这里的重点是我想强调设计模式不是禁用批判性分析的借口。另外，我想强调的是，不仅需要了解什么模式是什么，还需要了解为什么它们通常是一种好方法。
【问题讨论】：
标签： language-agnostic design-patterns
我有一个我维护的应用程序，它对几乎所有事情都使用提供者模式——几乎不需要。多层次的继承也是如此。例如，有一个由抽象 BaseDataProvider 实现的数据提供者接口，而后者又由 SqlDataProvider 扩展。在每个层次结构中，每种类型只有一个具体实现。显然，开发人员获得了一份关于实现企业架构的 Microsoft 文档，并且由于很多人使用这个应用程序，因此决定它需要所有的灵活性来支持多个数据库、多个企业目录和多个日历系统，即使我们只使用 MS SQL Server 、Active Directory 和 Exchange。
最重要的是，凭据、url 和路径等配置项在各处都进行了硬编码，并覆盖了通过参数传入更抽象类的数据。更改此应用程序很像在毛衣上拉线。你拉得越多，事情就会越多，最终你会改变整个代码来做一些本来应该很简单的事情。
我正在慢慢地重写它——部分是因为代码很糟糕，部分是因为它实际上是三个应用程序合二为一，甚至不需要其中一个。
【讨论】：
好吧，分享一点经验。在 C# 中，我有一个非常酷的设计，它使用了很多模式。我真的使用了很多模式，所以为了让故事简短，我不会一一列举。但是，当我用真实数据进行实际测试时，10^6 个对象并没有用我漂亮的设计“顺利运行”。通过分析它，我只是看到所有那些很好的多态类、代理等的间接级别都太多了。所以我想我可以用更好的模式重写它以提高效率，但我没有时间，所以我实际上在程序上破解了它，直到现在，好吧，它的工作方式更好......叹息，悲伤的故事。
【讨论】：
我见过一个 asp.net 应用程序，在该应用程序中，（当时初级，现在相当有能力）开发人员设法有效地使他的代码隐藏单身人士认为每个页面都是独一无二的，这在他的本地机器上运行得非常出色，直到测试人员正在争夺登录屏幕的控制权。
纯粹是对“独特”范围的误解和渴望使用这些设计模式东西的头脑。
【讨论】：