Question

你们当中有些人已经处理过这个问题了。当程序员被OO过度使用并忘记性能并拥有数据库时，它往往会发生。

举个例子，假设我们有一个电子邮件表，他们需要通过这个程序发送。在启动时，它会查找需要发送的任何内容，如下所示：

Emails = find_every_damn_email_in_the_database();
FOR Email in Emails
  IF !Email.IsSent() THEN Email.Send()

这是一个很好的从一个不重复你自己的角度来看，但有时这是不可避免的，它应该是：

Emails = find_unsent_emails();
FOR Email in Emails
  Email.Send()

这个名字有吗？

Answer 1

我会对它进行操作并将其命名为“懒惰过滤器（反）模式”。

Answer 2

我看过一次。那个程序员不是太久了。

我们称之为“firehose方法”。

Answer 3

对我而言，这是Joel Spolsky的leaky abstraction。

这并不完全是反模式，但是编写此代码的人并不真正了解Active Record模式抽象泄漏的位置。

Answer 4

我称之为“霰弹枪方法”。

Answer 5

我不确定这是否与数据库有关，因为你可能有一个复杂而昂贵的程序（例如，不仅仅是一个标志）来为一个组应用过滤器。

我不认为它有一个名字，因为第一个设计根本就不好，它违反了一个只承担责任的原则。如果您搜索，过滤和打印已过滤的数据，则需要将其重构为“已搜索过滤”并打印。

唯一与简单重构不同的是，它也会影响性能，就像内部循环可以以损害性能的方式设计一样。

Answer 6

似乎来自以下反模式：

原始开发人员可能不会被允许编写find_unsent_emails（）实现，因此会重用midget函数。然后，为什么要在开发和测试后进行更改？

Answer 7

这通常是因为使用现有查询然后在代码中过滤比添加新SQL查询要容易得多。也许是因为DBA控制所有查询并获得批准的新查询需要数天，或者可能是因为您使用的ORM工具使得定义自己的自定义查询非常困难。

如果我给它起名字，我称之为“简单出路”（反向）模式。无论是反模式还是不反模式都取决于个人情况。如果它总是需要检索的项目数量相当少，那么在代码中进行过滤确实不是一个大问题。但是如果项目数量很大并且有可能不断增长，那么显然应该在服务器上进行过滤。

Answer 8

我在其他地方看到过类似的问题，而不是一个简单的事情要做的事情，有一个基于“列表集群”的“事务集群”基于“集群集群”，基于“内存集群” 。毋庸置疑，最简单的事情就变成了一个非常棒的大骗子。

我称之为疾驰的普遍性。

Answer 9

Stoopid Amateurs。

说真的，我只是在拥有计算机科学学位并且根本没有专业经验的人中看过这个。当我在杜克大学教书时，我的顾问和我参加了一个“大规模编程”课程，让我们让人们看到这些错误。

Answer 10

第一个的表现实际上可以很好，具体取决于Emails的类型。如果它只是一个迭代器（考虑std::vector::begin()中的C++）那么它比将所有未发送的电子邮件首先存储在某个容器中更好和更好。

Answer 11

这个反模式有几个可能的名称。

Answer 12

The Daily WTF有一个很好的例子。

Answer 13

部分由1800年代的“懒惰过滤器（反）模式”启发，“功能失调的编程”（即功能编程的反面）怎么样？