在本文的第一部分中，我们介绍了谓词，这些谓词通过具有返回true或false的单个方法的简单接口，为Java等面向对象的语言带来了函数式编程的某些好处。 在第二部分和最后一部分中，我们将介绍一些更高级的概念，以使您的谓词发挥最大作用。

测试中

谓词发光的一种明显情况是测试。 每当您需要测试将遍历数据结构和某些条件逻辑混合在一起的方法时，通过使用谓词，您可以隔离地测试每一半，首先遍历数据结构，然后遍历条件逻辑。

第一步，您只需将始终为true或始终为false谓词传递给该方法即可摆脱条件逻辑，而只专注于对数据结构的正确处理：

// check with the always-true predicate
final Iterable<PurchaseOrder> all = orders.selectOrders(Predicates.<PurchaseOrder> alwaysTrue());
assertEquals(2, Iterables.size(all));// check with the always-false predicate
assertTrue(Iterables.isEmpty(orders.selectOrders(Predicates.<PurchaseOrder> alwaysFalse())));

在第二步中，您只需分别测试每个可能的谓词。

final CustomerPredicate isForCustomer1 = new CustomerPredicate(CUSTOMER_1);
assertTrue(isForCustomer1.apply(ORDER_1)); // ORDER_1 is for CUSTOMER_1
assertFalse(isForCustomer1.apply(ORDER_2)); // ORDER_2 is for CUSTOMER_2

这个例子很简单，但是您可以理解。 为了测试更复杂的逻辑，如果测试功能的每半部分还不够，则可以创建模拟谓词，例如，一次返回true的谓词，然后始终返回false。 由于严格分离关注点，因此强制这样的谓词可以大大简化您的测试设置。

谓词对于测试非常有用，以至于如果您倾向于做一些TDD，我的意思是说，如果您可以通过测试的方式影响您的设计方式，那么一旦您知道谓词，它们肯定会找到进入您设计的方式。

向团队解释

在我从事的项目中，团队最初并不熟悉谓词。 但是，这个概念很简单，也很有趣，每个人都可以快速上手。 实际上，令我惊讶的是，谓词的概念如何从我编写的代码自然传播到我的同事的代码中，而没有太多的福音。 我想谓词的好处不言而喻。 从诸如Apache或Google之类的知名公司那里获得成熟的API，也有助于说服它是严肃的东西。 现在有了功能性编程炒作，它应该更容易出售！

简单优化

通常的优化是使谓词尽可能不变和无状态 ，以使它们的共享无需考虑线程。 这样就可以在整个过程中使用一个实例（作为一个实例，例如作为静态最终常量）。 如果需要，可以在运行时缓存在编译时无法枚举的最常用谓词。 与往常一样，仅当您的探查器报告确实需要它时，才执行此操作。

可能的话，谓词对象可以在其构造函数中（自然是线程安全的）或惰性地预先计算其评估所涉及的一些计算。

谓词应无副作用 ，即“只读”：谓词的执行不应引起系统状态的任何可观察到的变化。 某些谓词必须具有某种内部状态，例如用于分页的基于计数器的谓词，但它们仍不得更改其所应用系统中的任何状态。 在内部状态下，它们也无法共享，但是，如果它们支持每次连续使用之间的重置，则可以在其线程内重用它们。

细粒度的接口：谓词的受众更大

在大型应用程序中，您会发现自己为完全不同的类型编写了非常相似的谓词，但它们具有与客户相关的共同属性。 例如，在管理页面中，您可能希望按客户过滤日志； 在CRM页面中，您要按客户过滤投诉。

对于每个此类X，您都需要另一个CustomerXPredicate来按客户对其进行过滤。 但是由于每个X都以某种方式与客户相关，所以我们可以使用一种方法将其（在Eclipse中提取接口）分解为一个CustomerSpecific接口：

public interface CustomerSpecific {Customer getCustomer();
}

这个细粒度的界面让我想起了某些语言的特质 ，但它没有可重用的实现。 它也可以看作是在静态类型语言中引入动态类型的一种方法，因为它可以使用getCustomer （）方法以不同的方式调用任何对象。 当然，我们的类PurchaseOrder现在实现了此接口。

一旦有了CustomerSpecific接口，就可以在其上定义谓词，而不是像以前那样在每个特定类型上定义谓词。 这有助于在整个大型项目中利用少数谓词。 在这种情况下，谓词CustomerPredicate与它运行的CustomerSpecific接口位于同一位置，并且具有通用类型CustomerSpecific ：

public final class CustomerPredicate implements Predicate<CustomerSpecific>, CustomerSpecific {private final Customer customer;// valued constructor omitted for claritypublic Customer getCustomer() {return customer;}public boolean apply(CustomerSpecific specific) {return specific.getCustomer().equals(customer);}
}

请注意，该谓词本身可以实现CustomerSpecific接口，因此甚至可以对其进行评估！

在使用类似特征的接口时，您必须注意泛型并稍微更改类PurchaseOrders中需要Predicate <PurchaseOrder>的方法，以便它也可以接受PurchaseOrder超类型的任何谓词：

public Iterable<PurchaseOrder> selectOrders(Predicate<? super PurchaseOrder> condition) {return Iterables.filter(orders, condition);
}

域驱动设计规范

埃里克·埃文斯（Eric Evans）和马丁·福勒（Martin Fowler）一起编写了规范Specification ，这显然是一个谓词。 实际上，“谓词”一词是逻辑编程中使用的词，并且编写了规范说明用于说明我们如何将逻辑编程的某些功能借用到面向对象的语言中。

在《域驱动设计》一书中，埃里克·埃文斯（Eric Evans）详细介绍了这种模式，并给出了几个规范的示例，这些示例均表示域的各个部分。 就像本书所描述的策略模式一样，当将策略模式应用于领域时，从某种意义上说，规范模式也可以被认为是领域领域谓词的一种版本，其另外的目的是清楚地标记和标识该领域。商业规则。

作为说明，Specification模式中建议的方法名称为： isSatisfiedBy（T）：boolean ，它重点关注域约束。 正如我们之前用谓词所见，封装在Specification对象中的业务逻辑原子可以使用布尔逻辑（或（而不是全部）逻辑）重新组合，就像在Interpreter模式中一样 。

该书还介绍了一些更高级的技术，例如查询数据库或存储库时的优化以及使用。  

查询时的优化

以下是优化技巧，但我不确定您是否会需要它们。 但这确实是事实，谓词在过滤数据集时非常笨拙：必须仅对集合中的每个元素进行评估，这可能会导致大型集合的性能问题。 如果将元素存储在数据库中并提供了谓词，那么通过谓词检索每个元素以逐个过滤它们对于大型集合来说似乎并不是一个正确的主意……

遇到性能问题时，可以启动分析器并找到瓶颈。 现在，如果经常调用谓词从数据结构中过滤出元素是一个瓶颈，那么如何解决呢？

一种方法是摆脱完整的谓词，然后回到硬编码，更易于出错，重复且测试较少的代码。 只要我能找到更好的替代方案来优化谓词，我就会一直反对这种方法，并且有很多选择。

首先，深入了解代码的使用方式。 本着领域驱动设计的精神，每当出现问题时，就应该系统地寻找领域的见解。

通常，系统中有明确的使用模式。 尽管统计，它们为优化提供了巨大的机会。 例如，在我们的PurchaseOrders类中，检索每个PENDING订单的频率可能比其他所有案例都要高得多，因为在我们的虚构示例中，从业务角度来看，这样做才有意义。

朋友共谋

根据使用模式，您可以编写专门针对其优化的替代实现。 在我们经常查询待处理订单的示例中，我们将编写一个替代实现FastPurchaseOrder ，该实现使用一些预先计算的数据结构来使待处理订单准备就绪以便快速访问。

现在，为了从此替代实现中受益，您可能很想更改其接口以添加专用方法，例如selectPendingOrders（） 。 请记住，在您只有通用的selectOrders（Predicate）方法之前。 添加额外的方法在某些情况下可能还不错，但可能会引起一些问题：您还必须在其他所有实现中都实现此额外的方法，并且额外的方法可能对特定的用例而言过于具体，因此可能不适用于接口。

通过仅期望谓词的完全相同的方法使用内部优化的技巧只是使实现认识到它所关联的谓词。 我称其为“ Friend Complicity ”，是指C ++中的friend关键字。

/** Optimization method: pre-computed list of pending orders */
private Iterable<PurchaseOrder> selectPendingOrders() {// ... optimized stuff...
}public Iterable<PurchaseOrder> selectOrders(Predicate<? super PurchaseOrder> condition) {// internal complicity here: recognize friend class to enable optimizationif (condition instanceof PendingOrderPredicate) {return selectPendingOrders();// faster way}// otherwise, back to the usual casereturn Iterables.filter(orders, condition);
}

显然，它增加了两个实现类之间的耦合，否则它们应该彼此忽略。 而且，仅当直接给«friend»谓词而没有修饰符或复合词时，它才有助于提高性能。

Friend Complicity真正重要的是确保方法的行为永不妥协，无论是否进行优化，都必须始终满足接口的约定，只是性能改进可能会或不会发生。 另外请记住，您可能有一天可能要切换回未经优化的实施。  

SQL受损

如果订单实际上存储在数据库中，则可以使用SQL快速查询它们。 顺便说一句，您可能已经注意到谓词的概念恰好是您在SQL查询中的WHERE子句之后放置的。

仍然使用谓词并提高性能的第一种简单方法是，使某些谓词使用方法asSQL（）实现额外的接口SqlAware ：String ，该字符串返回与谓词本身的评估相对应的确切SQL查询 。 当对数据库支持的存储库使用谓词时，存储库将调用此方法，而不是通常的validate（Predicate）或apply（Predicate）方法，然后使用返回的查询来查询数据库。

我称这种方法是SQL受损的，因为谓词现在已被特定于数据库的详细信息所污染，因此应该更经常地忽略它。

直接使用SQL的替代方法包括使用存储过程或命名查询 ：谓词必须提供查询的名称及其所有参数。 在存储库和传递给它的谓词之间进行双调度也是一种选择：存储库在其附加方法selectElements（this）上调用谓词，该附加方法本身又调用正确的预选择方法findByState（state）：存储库中的Collection ； 谓词然后对返回的集合应用其自己的过滤，并返回最终的过滤集合。

包容性

包含是一个逻辑概念，用于表达一个概念包含另一个概念的关系，例如“红色，绿色和黄色包含在术语颜色下”（ Merriam-Webster ）。 谓词之间的包含可能是在代码中实现的非常强大的概念。

让我们以广播股票报价的应用程序为例。 注册时，我们必须声明我们有兴趣观察哪些报价。 我们可以通过简单地传递一个只对我们感兴趣的股票评估为真的股票谓词来做到这一点：

public final class StockPredicate implements Predicate<String> {private final Set<String> tickers;// Constructors omitted for claritypublic boolean apply(String ticker) {return tickers.contains(ticker);}}

现在，我们假设该应用程序已经广播了有关消息传递主题的标准的流行行情设置，并且每个主题都有自己的谓词。 如果它可以检测到我们要使用的谓词是“包括”，或包含在标准谓词之一中，我们可以订阅它并保存计算。 在我们的情况下，通过简单地在谓词上添加其他方法，这种包含就相当容易了：

public boolean encompasses(StockPredicate predicate) {return tickers.containsAll(predicate.tickers);}

总体而言，请记住，一般情况下很难实现包容，但是即使部分包容也可能非常有价值，因此它是工具箱中的重要工具。

结论

谓词很有趣，可以增强您的代码和您的思考方式！

干杯，

该部分的单个源文件可下载cyriux_predicates_part2.zip（固定的损坏链接）

参考： 带有谓词的纯Java语言中的函数式风格– Cyrille Martraire博客博客中来自JCG合作伙伴 Cyrille Martraire的第二部分 。