功能Java示例第6部分

这是称为“ Functional Java by Example”的系列文章的第6部分。

我在本系列的每个部分中发展的示例是某种“提要处理程序”，用于处理文档。在前面的部分，我们试图通过移动尽可能多的副作用，如IO，该系统的外部，以使我们的纯可能的功能。

现在，我们将一些抽象替换为函数，以作为参数传递。

如果您是第一次来，最好是从头开始阅读。 它有助于了解我们从何处开始以及如何在整个系列中继续前进。

这些都是这些部分：

第1部分–从命令式到声明式
第2部分–讲故事
第3部分–不要使用异常来控制流程
第4部分–首选不变性
第5部分–将I / O移到外部
第6部分–用作参数
第7部分–将失败也视为数据
第8部分–更多纯函数

我将在每篇文章发表时更新链接。如果您通过内容联合组织来阅读本文，请查看我博客上的原始文章。

每次代码也被推送到这个GitHub项目。

OO型协作者

还记得我们以前留下的东西吗？

class FeedHandler {Webservice webserviceList<Doc> handle(List<Doc> changes) {changes.findAll { doc -> isImportant(doc) }.collect { doc ->createResource(doc).thenApply { resource ->setToProcessed(doc, resource)}.exceptionally { e ->setToFailed(doc, e)}.get()}}private CompletableFuture<Resource> createResource(doc) {webservice.create(doc)}private static boolean isImportant(doc) {doc.type == 'important'}private static Doc setToProcessed(doc, resource) {doc.copyWith(status: 'processed',apiId: resource.id)}private static Doc setToFailed(doc, e) {doc.copyWith(status: 'failed',error: e.message)}}

上面的提要处理程序需要一个“ Web服务”来完成其工作。

请看以下部分，其中使用WebService类型的协作者来基于文档创建资源：

class FeedHandler {Webservice webserviceList<Doc> handle(List<Doc> changes) {changes.collect { doc ->createResource(doc)...}private CompletableFuture<Resource> createResource(doc) {webservice.create(doc)}}

请记住，作为异常处理机制的一部分，我们将其包装在CompletableFuture ，而不是直接返回资源。

如果我们想要WebService以外的其他资源来创建资源怎么办？

好吧，这是同时变得棘手和容易的地方-OO风格可能与FP风格有些冲突。

您会看到， WebService是一个Java接口，定义如下：

interface Webservice {CompletableFuture<Resource> create(Doc doc)
}

这遵循了Dependency Inversion Principle（DIP） ，它是Robert C. Martin提倡的SOLID设计原则的一部分，该原则（其中包括）说：

抽象不应依赖细节。细节应取决于抽象。

WebService已经是任何类型的Webservice 实现的抽象。因此，系统可以具有此接口的多种实现，例如REST实现和SOAP实现：

class RestWebService implements Webservice {@OverrideCompletableFuture<Resource> create(Doc doc) {// do REST communication}
}
class SoapWebService implements Webservice {@OverrideCompletableFuture<Resource> create(Doc doc) {// do SOAP communication}
}

提要处理程序不关心细节，它只是想要一些符合WebService接口定义的协定的东西：有一个create方法可以接受Doc并返回CompletableFuture 。

FeedHandler类具有一个webservice属性，其中包含对WebService的引用。任何OO开发人员都可以识别这种样式，因为它非常熟悉：所有协作者都存在于属性中，这些属性（通常）是在构造过程中初始化的。

一旦构造了FeedHandler ，就可以通过DI框架或普通的手工方法将传递的WebService实例传递给它-尽管构造函数注入或属性注入。

为了简洁起见，我一直在代码片段中省略了构造函数，但是正如您在测试用例中所看到的那样，我绝对使用Groovy为我生成的构造函数来传递所有依赖项。

协作者FP风格

好的，如果我们再次戴上Functional Hat，我们将需要重新审视将WebService传递到提要处理程序的方式。

该handle方法的签名不提比其他任何东西：文件进去，文件出来。

class FeedHandler {...List<Doc> handle(List<Doc> changes) {...}}

我不能假定将返回相同的输入 相同的输出 -因为该方法暗中依赖于外的东西：对WebService 。

好吧，也许我可以控制供稿处理程序的整个创建过程，包括WebService ，但是在方法调用之间可以更改对webservice引用，每次handle使用它时都会产生其他结果。 除非我将其设为不可变的，否则将阻止引用的更新。 我告诉过你可能会很棘手

是否可以像上一期中使用isImportant ， setToProcessed和setToFailed方法一样使handle pure ？

在这种情况下，我们必须将WebService作为参数传递，就像传递文档列表一样。

我们改变

class FeedHandler {Webservice webserviceList<Doc> handle(List<Doc> changes) {...}}

进入

class FeedHandler {List<Doc> handle(List<Doc> changes, Webservice webservice) {...}}

在每次调用handle我们都会传递它需要的所有内容：需要处理的文档和需要使用的Web服务。

由于此方法不再依赖于FeedHandler类中的任何属性，因此我们现在可以使其变为static -将其升级为类级方法。

功能性Java

高阶函数

实际上，我们的handle方法刚刚变成了所谓的“高阶函数”，即接受一个函数或返回一个函数的函数。

因此，回到我最初提出的一个问题： 如果我们想要WebService之外的其他东西来创建资源该怎么办？

它甚至不应该是Web服务吗？也许我们完全想吃香蕉，一只猴子为我们创造资源？

class Monkey implements Webservice {@OverrideCompletableFuture<Resource> create(Doc doc) {// go bananas! But do create resources plz}
}

看起来很奇怪，不是吗？对于抽象提要处理程序的需要， WebService接口太具体了。任何创造资源的东西都会起作用，不是吗？

更好的名称是“ ResourceCreator” ，因此只需重命名接口即可。

旧：

interface Webservice {CompletableFuture<Resource> create(Doc doc)
}

新：

interface ResourceCreator {CompletableFuture<Resource> create(Doc doc)
}

具有create方法的ResourceCreator接口；多么合身！现在任何东西都可以实现此接口，并且提要处理程序甚至不在乎它是Web服务，猴子还是霍比特人。

新方法签名：

class FeedHandler {List<Doc> handle(List<Doc> changes, ResourceCreator creator) {...}}

完美的抽象！

功能抽象

在Java中，我们将只有一种抽象方法的接口称为功能接口 。我们的ResourceCreator符合此描述；它只有一个抽象方法create 。

Java的java.util.function程序包具有许多这样的功能接口-它们每个都有一个已定义的目的：

Consumer表示一个接受参数且不返回任何值的函数
Supplier表示不接受任何参数的函数，仅返回结果
Function表示接受一个参数并返回结果的函数
…和更多

这意味着，我们不需要每次都需要一个函数“接受一个参数并返回结果”时就定义一个特定的接口，例如ResourceCreator － Function已经是一个我们可以利用的接口！

这就是Java 8中的Function （简体）的样子：

interface Function<T,R> {R apply(T t);
}

这就是ResourceCreator现在的样子：

interface ResourceCreator {CompletableFuture<Resource> create(Doc doc)
}

您将看到，如果满足以下条件，我们可以用Function完全替代ResourceCreator ：

用Doc代替R型
用T型替代CompletableFuture
用方法替代调用create apply

我们可以完全擦除ResourceCreator界面！

新方法签名将变为：

class FeedHandler {List<Doc> handle(List<Doc> changes,Function<Doc, CompletableFuture<Resource>> creator) {...}}

我们取得了什么成就？

我们现在可以传递任何要handle 函数，该函数需要一个Doc并产生一个CompletableFuture —这就是feed处理程序正常工作所需的全部。
正如您现在可能已经注意到的，函数编程处理了很多函数。一个函数可以采用另一个函数，也可以返回一个函数。
从Java 8开始，我们已经准备好了很多功能接口。每个开发人员都可以以标准化的方式与他们合作，因此最好查看它们是否适合您的用例和API，并尽可能重用它们。他们每个人都有泛型类型（如T和R可以由你来表明在发生什么，什么来的函数的输出）。

现在，完整的代码如下所示：

class FeedHandler {List<Doc> handle(List<Doc> changes,Function<Doc, CompletableFuture<Resource>> creator) {changes.findAll { doc -> isImportant(doc) }.collect { doc ->creator.apply(doc).thenApply { resource ->setToProcessed(doc, resource)}.exceptionally { e ->setToFailed(doc, e)}.get()}}private static boolean isImportant(doc) {doc.type == 'important'}private static Doc setToProcessed(doc, resource) {doc.copyWith(status: 'processed',apiId: resource.id)}private static Doc setToFailed(doc, e) {doc.copyWith(status: 'failed',error: e.message)}}

现在就这样！下次，我们将处理故障数据。

如果您有任何意见或建议，我很想听听他们的意见！