问题标签 [anti-patterns]

是否曾经证明使用公认的反模式在某个特定情况下确实有效？你有没有通过使用反模式在你的一个项目中解决问题或获得任何好处？

有人可以向我解释 OOP 中的接口膨胀是什么（最好有一个例子）。

替代文字 http://img8.imageshack.us/img8/8558/classdiagram.png

简短描述：我怀疑AbstractCrudDaoImpl实现从同一个父级（ReadOnlyDao）继承的接口和抽象类是否正常。

所以我在库中编写了一堆或多线程的代码，这些代码将在后台运行。所以我让 UI 传入 SynchronizationContext 对象，这样我就可以将事件发布回主 UI 线程。

许多不同的对象都有 UI 可以订阅的公共事件。我最初只是将 SyncContext 对象作为参数添加到初始化我的库的创建调用中。一旦传入，我将它存储在静态类的静态变量中，从而使其全局可访问（尽管它是内部的）。

我喜欢这样，因为每当我需要在 UI 线程上运行一些代码时，我都可以轻松地做到这一点，而无需修改太多代码。但这意味着我的很多代码都依赖于不明确的静态类。使依赖项显式需要大量代码更改以将其添加到使用该变量的任何类的构造函数中，并将对它的引用存储在任何类中，甚至创建需要它的对象。

所以我有选择

A) 为我的 SynchronizationContext 隐藏依赖项的静态变量

B) 几乎每个班级都知道并绕过我的 SynchronizationContext。

对于这种情况，还有另一种更好的模式吗？

.net 框架 3.5。主 UI 将是 WPF，但我们希望它也可以与 winforms 一起使用。

为什么像 Microsoft Excel、Gnumeric 和 OpenOffice.org Calc 这样的程序在设计时对行数和列数进行了硬编码限制？当电子表格被认为是要求苛刻的应用程序并且动态内存分配被认为是“高端”时，这似乎是一种古老的编程技术。我猜这表明某些资源正在被静态分配，并假设“没有人需要更多”，从而在应用程序中引入了非常任意的限制。其背后的逻辑是什么？

注意：我知道有些人会争辩说这个问题与编程无关。这是一个先发制人的反驳：这个问题与编程有关，因为它询问为什么使用普遍且看似过时的编程方法。

在为我的基于服务器的应用程序考虑了一些架构问题之后，我觉得我将不得不使用单例来实现我的目标。纯粹出于以下原因（证明我的气味是合理的）：

• 我不需要将昂贵的对象深入到调用堆栈中
• 我可以在任何上下文中对单例管理对象执行功能。（很多代码已经存在，因此我不愿意重写大量其他工作代码）

除此之外，单身人士提出了另一个问题。我的基于服务器的应用程序本质上是一个 DLL，它带有一个可以调用多个服务器实例的类。服务器实例类包含单例管理对象。通常，这将由 Windows 服务管理，因此服务器：机器比率将为 1:1。

因此，您可以将其视为（其中 -> 是 1:1，=> 是 1:many）：

MACHINE -> ServiceHost（Windows 服务？） -> 服务器实例 -> 单例管理对象

但是，我们希望允许 SaaS 模型，这需要服务主机（无论是 Windows 服务还是 Win32 应用程序）能够根据业务需要启动多个服务器。因此，一台物理机可以运行单个服务器主机，该主机将运行多个服务器实例。

这将是（其中 -> 是 1:1，=> 是 1:many）：

MACHINE -> ServiceHost（Windows 服务？）=>服务器实例 ->单例管理对象

问题是这些单例将在服务器之间共享。这不可能发生。单例必须与服务器实例 1:1。

假设我无法摆脱这些单例，我是否可以通过将服务实例类作为单独的进程/内存空间调用来将这些服务器实例彼此分开？

我只能想象我需要启动多个 EXE（并使用 WCF 来管理），每个服务器实例一个。这显然不是很好。

在为企业构建应用程序时要避免哪些关键反模式？我们正在使用 C#、SQL Server 和 Silverlight，顺便说一句 - 但我想一些反模式将是语言中立的。

我最近遇到了一个术语“上帝对象”，它被描述为“反模式”。我听说过糟糕的编码实践，但我从未听说过这样描述它们。

所以我前往 Wikipedia 了解更多信息，我发现有一种称为“馄饨代码”的反模式，它被描述为“以许多小型且（理想情况下）松散耦合的软件组件为特征”。

我很困惑——为什么这是一件坏事？

可能的重复：
关于设计模式：何时使用单例？

这个问题不是关于单例是否总体上“被认为是有害的”。根据您的经验，我只想知道单例在哪些特定情况下似乎可以很好地工作。

编辑： 请，如果您想讨论单身人士的适当性和/或邪恶性，有一个已经存在的问题：137975、11831

哎呀！我刚刚发现我的问题已经在这里提出了：关于设计模式：何时使用单例？

情况是这样的：您有两个类都实现了相同的接口，并且两个类一起工作以完成一些业务流程。

例如networkUserManager，并localUserManager实现IUserManager了一个方法getUser()。 networkUserManager.getUser()将获取 a 的请求放入User队列并返回回复。 localUserManager.getUser()从队列中获取请求，在某个数据库中查找用户信息，然后用用户数据进行回复。

当我看到类似的事情正在做时，我不禁怀疑这是否是糟糕的设计。这是一个糟糕的设计吗？如果不是，那么做这样的事情是个好主意的例子是什么？