问题标签 [anti-patterns]

考虑一个包含表 Products 和Employees 的数据库。对当前的产品经理进行建模有一个新的要求，他们是负责产品的唯一员工，并指出有些产品足够简单或成熟，不需要产品经理。也就是说，每个产品可以有零个或一个产品经理。

方法一：alter tableProduct添加一个新的NULLable 列product_manager_employee_ID，这样一个没有产品经理的产品就可以通过这个NULL值来建模。

方法 2：创建一个新表ProductManagers，其中包含不可NULL列的列，product_ID并且employee_ID对 具有唯一约束product_ID，因此没有产品经理的产品通过该表中缺少行来建模。

还有其他方法，但这是我最常遇到的两种。

假设这些都是合法的设计选择（我倾向于相信）并且仅仅代表不同的风格，他们有名字吗？我更喜欢方法 2，并且发现很难在不使用实际示例的情况下向喜欢方法 1 的人传达风格上的差异（就像我在这里所做的那样！）如果我可以说，“我更喜欢倾向6NF（或其他）风格我自己。”

假设其中一种方法实际上是一种反模式（我只是怀疑方法 1 可能是通过将两个实体之间的关系建模为其中一个实体的属性）这种反模式有名称吗？

我正在研究模式和反模式。我对模式有一个清晰的概念，但我没有反模式。来自网络和维基百科的定义让我很困惑。

谁能用简单的话向我解释什么是反模式？什么目的？他们在做什么？这是坏事还是好事？

在我工作的这些年里，我注意到了一种我认为是反模式的明显趋势：将内部数据维护为大的 XML 字符串。尽管两个最严重的违规者非常相似，但我已经看到了很多不同的方法。

网络服务

第一个应用程序是 Web 服务，它提供对 SQL 数据库中潜在的大量数据的访问。在启动时，它或多或少地从数据库中提取所有数据，并将其作为 XML 存储在内存中。（三次。）此应用程序的所有者称其为缓存。我称之为慢，因为在解决这个问题时遇到的每一个性能问题都可以直接追溯到这个东西。（这是一个公司环境，毫无疑问，客户端会因为性能故障而不是服务而受到指责。）这个应用程序确实使用了 XML DOM。

进口商

第二个应用程序读取作为从第三方数据库导出的结果而生成的 XML 文件。目标是将这些数据导入专有系统（归我们所有）。执行此操作的应用程序读取整个 XML 文件，并在整个导入序列中维护至少两个、有时多达四个 XML 文件的副本。请注意，数据可以在导入之前进行操作、转换和配置，因此导入器在其整个生命周期内都拥有 XML 格式的数据。不出所料，当提供一个中等大小的 XML 文件时，这个导入器就会爆炸。此应用程序仅将 XML DOM 用于其中一个副本，其余的都是原始 XML 字符串。

我对常识的理解表明，XML不是一种在内存中保存数据的好格式，而是数据在输出/传输时应转换为 XML，并在读入和导入时转换为内部数据结构。问题是，我经常遇到完全忽略可伸缩性问题的生产代码，并且为此付出了大量额外的努力。（这些应用程序中字符串解析的庞大数量令人恐惧。）

这是一个常见的失败，没有为其他人遇到的工作应用正确的工具吗？还是只是我运气不好？还是我错过了一些非常明显和好的情况，在这些情况下将大量数据存储在内存中作为 XML 是正确的和好的？

对我来说，Interpreter 模式听起来很像被称为 Greenspun 第十条规则的反模式：

任何足够复杂的 C 或 Fortran 程序都包含一个临时的、非正式指定的、充满错误的、缓慢的 Common Lisp 一半的实现。

也就是说，如果您需要使用解释器，您可能会创建一些缓慢、临时且指定不明确的东西。正确的解决方案是从一开始就使用正确的语言。

或者，也可以将一种众所周知的、明确指定的语言嵌入到您的应用程序中，例如 Guile（GNU 可嵌入方案）。或者使用 Haskell 作为嵌入式领域特定语言。

但我在实践中还没有看到这一点——您在构建自己的嵌入式语言方面有什么经验？这是个好主意吗？它比嵌入已经存在的语言更好吗？

（我不是特别喜欢 lisp。这很好，但 C、Haskell 和 python 以及许多其他语言也是如此。）

是什么导致计算机程序变成大泥球？是否有可能从这种反模式中恢复？是否有可以应用的经过验证的重构方法？

我正在阅读 Wikipedia 上的 Singleton 文章，我遇到了这个例子：

虽然我真的很喜欢这个 Singleton 的行为方式，但我看不出如何调整它以将参数合并到构造函数中。在 Java 中执行此操作的首选方法是什么？我必须做这样的事情吗？

谢谢！

编辑：我想我对使用 Singleton 的渴望已经引发了一场争议风暴。让我解释一下我的动机，希望有人能提出一个更好的主意。我正在使用网格计算框架来并行执行任务。一般来说，我有这样的事情：

发生的情况是，即使我只是将我的数据的引用传递给所有任务，当任务被序列化时，数据也会被一遍又一遍地复制。我想做的是在所有任务之间共享对象。当然，我可能会像这样修改类：

如您所见，即使在这里我也有一个问题，即在通过第一个文件路径后，传递不同的文件路径没有任何意义。这就是为什么我喜欢在答案中发布的商店的想法。无论如何，我不想在 run 方法中包含加载文件的逻辑，而是想将此逻辑抽象为一个 Singleton 类。我不会再举一个例子，但我希望你能明白。请让我听听您的想法，以更优雅的方式完成我正在尝试做的事情。再次感谢你！

情况是这样的：我有一堂课做得太多了。它主要用于访问配置信息，但它也有数据库连接。它是作为单例实现的，因此这也使单元测试变得困难，因为大多数代码都与它紧密耦合。这更成问题，因为它创建了一个导入时依赖项（我们在 Python 中这样做），这意味着某些模块必须按特定顺序导入。理想情况下，我想将其分为两个类并使其成为非单例。

幸运的是，我的雇主已经意识到这种测试是好的，并且如果它使代码更具可测试性，他愿意允许我进行这样的更改。但是，我怀疑他们是否愿意让我在上面花费太多时间。我宁愿逐步解决这个问题，也不愿过于激进。

所以，我在这里看到三个选择：

1. 将配置对象分解为（单例）配置对象和（非单例）数据库对象。这至少可以让我将数据库作为导入时依赖项删除。
2. 使配置对象成为非单例并将其传递给需要它的对象。我觉得这更好地满足了我们的短期需求，但我认为这需要更多的时间。
3. 做一些我没有想到的你在回答中建议的事情。:-)

那我该怎么办？

在 Java 类中，使用 getter 和 setter 访问成员字段是好还是坏？

例如哪个更好：

一般来说，由于 KISS 原则，我认为直接访问该字段是最好的，并且稍后有人可能会覆盖 get 方法，结果无法预测。

然而，我的同事认为最好保留一层抽象。对此是否有共识？

在使用 C# 或 Java 等其他语言构建基于 GUI 的大型应用程序时，我们有各种模式，如 MVP、MVC、MVVM，甚至还有完整的指导包，如 Prism (WPF/Silerlight)，帮助我们保持代码的可维护性、可扩展性并保持复杂性应用程序处于理智的水平。

但是当谈到用 html/javascript 编写的大型 RIA 应用程序时，我发现很难找到任何真正好的资源。

在 html/javascript 中创建大型 RIA 应用程序（用于创建 Gmail、Google Calender、Google Docs 等应用程序）的注意事项是什么？

我最近阅读了一篇关于“贫血域模型模式”的文章，引起了我的注意。当我阅读本文时，我发现贫血域模型描述适用于我从事和构建的许多项目。我从不认为这是一个糟糕的设计决定，因为它感觉很自然。我认为在域模型重量轻且不是很复杂的情况下，贫血域模型这个名字非常适合。为什么要在不需要的领域模型中增加复杂性，以至于“贫血领域模型”的标题不能恰当地描述您的代码？

问题：在什么时候将更多的代码复杂性填充到您的服务/应用程序层中变得不正确而有利于暴露实体对象的复杂性？我完全赞成在实体上拥有一个“总计”属性，它可以在内部计算出总计的值。我不是为了让实体直接与其他各种小部件通信以确定它的属性之一的结果。那么贫血域模型的概念是反模式还是良好的关注点分离？标题贫血域模型总是一件坏事吗？

只是好奇其他人对这种设计（反）模式的想法。