设计模式滥用的例子

Question

设计模式很棒，因为它们将潜在的复杂技术提炼成惯用的东西。通常只是它有一个名字有助于沟通和理解。

缺点是它更容易尝试将它们用作银弹，将它们应用于每种情况而不考虑它们背后的动机，并花一秒时间来考虑一种给定的模式是否真的适合这种情况

与this question不同，我并不是在寻找经常滥用的设计模式，但我很乐意看到一些非常可靠的设计模式的例子。我正在寻找有人“错过了重点”并且应用了错误模式，甚至执行错误的情况。

重点是，我希望能够强调设计模式不是禁用批判性分析的借口。另外，我想强调不仅需要了解模式的 ，而为什么它们通常是一种很好的方法。

Answer 1

我有一个我维护的应用程序，它几乎可以使用提供程序模式 - 几乎不需要。多级继承也是如此。作为一个例子，有一个数据提供者接口，它由一个抽象的BaseDataProvider实现，然后由一个SqlDataProvider扩展。在每个层次结构中，每种类型只有一个具体实现。显然，开发人员获得了关于实施企业架构的Microsoft文档，并且因为很多人使用这个应用程序，所以决定它需要所有灵活性来支持多个数据库，多个企业目录和多个压延系统，即使我们只使用MS SQL Server ，Active Directory和Exchange。

最重要的是，凭证，网址和路径等配置项在整个地方都是硬编码的，并覆盖通过参数传递给更抽象类的数据。改变这个应用程序很像是穿上毛衣的线程。你抓的越多，解开的东西越多，你最终会在整个代码中做出改变，做一些应该很简单的事情。

我正在慢慢地重写它 - 部分是因为代码很糟糕，部分是因为它实际上是三个应用程序汇总成一个，其中一个甚至不需要。

Answer 2

好吧，分享一些经验。在C＃中，我有一个非常酷的设计，使用了很多模式..我真的使用了很多它们，所以为了使故事简短，我不会说出一切。但是，当我实际使用真实数据进行测试时，10 ^ 6个对象并没有以我漂亮的设计“顺利运行”。通过分析它，我只是看到所有那些间接级别的很好的多态性类，代理等都太多了......所以我想我可以用更好的模式重写它以使它更有效但我没有时间，所以我几乎在程序上攻击它，直到现在，它的工作方式更好......叹息，悲伤的故事。

Answer 3

我见过一个asp.net应用程序，其中（当时是初级的，现在非常有能力的）开发人员设法有效地使他的代码隐藏单身人士认为每个页面都是独一无二的，在他的本地机器上运行得非常好直到测试人员正在争取控制登录屏幕。

纯粹是对“独特”范围的误解，以及渴望使用这些设计模式的东西。