毕设网站建设论文,小程序开发模板,闸北网站推广公司,网站建设销售模式这是称为“ Functional Java by Example”的系列文章的第6部分。 我在本系列的每个部分中发展的示例是某种“提要处理程序”#xff0c;用于处理文档。 在前面的部分#xff0c;我们试图通过移动尽可能多的副作用#xff0c;如IO#xff0c;该系统的外部#xff0c;以使我… 这是称为“ Functional Java by Example”的系列文章的第6部分。 我在本系列的每个部分中发展的示例是某种“提要处理程序”用于处理文档。 在前面的部分我们试图通过移动尽可能多的副作用如IO该系统的外部以使我们的纯可能的功能。 现在我们将一些抽象替换为函数以作为参数传递。 如果您是第一次来最好是从头开始阅读。 它有助于了解我们从何处开始以及如何在整个系列中继续前进。 这些都是这些部分 第1部分–从命令式到声明式 第2部分–讲故事 第3部分–不要使用异常来控制流程 第4部分–首选不变性 第5部分–将I / O移到外部 第6部分–用作参数 第7部分–将失败也视为数据 第8部分–更多纯函数 我将在每篇文章发表时更新链接。 如果您通过内容联合组织来阅读本文请查看我博客上的原始文章。 每次代码也被推送到这个GitHub项目 。 OO型协作者 还记得我们以前留下的东西吗 class FeedHandler {Webservice webserviceListDoc handle(ListDoc changes) {changes.findAll { doc - isImportant(doc) }.collect { doc -createResource(doc).thenApply { resource -setToProcessed(doc, resource)}.exceptionally { e -setToFailed(doc, e)}.get()}}private CompletableFutureResource 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 webserviceListDoc handle(ListDoc changes) {changes.collect { doc -createResource(doc)...}private CompletableFutureResource createResource(doc) {webservice.create(doc)}} 请记住 作为异常处理机制的一部分我们将其包装在CompletableFuture 而不是直接返回资源。 如果我们想要WebService以外的其他资源来创建资源怎么办 好吧这是同时变得棘手和容易的地方-OO风格可能与FP风格有些冲突。 您会看到 WebService是一个Java接口定义如下 interface Webservice {CompletableFutureResource create(Doc doc)
} 这遵循了Dependency Inversion PrincipleDIP 它是Robert C. Martin提倡的SOLID设计原则的一部分该原则其中包括说 抽象不应依赖细节。 细节应取决于抽象。 WebService已经是任何类型的Webservice 实现的抽象。 因此系统可以具有此接口的多种实现例如REST实现和SOAP实现 class RestWebService implements Webservice {OverrideCompletableFutureResource create(Doc doc) {// do REST communication}
}
class SoapWebService implements Webservice {OverrideCompletableFutureResource 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 {...ListDoc handle(ListDoc changes) {...}} 我不能假定将返回相同的输入 相同的输出 -因为该方法暗中依赖于外的东西对WebService 。 好吧也许我可以控制供稿处理程序的整个创建过程包括WebService 但是在方法调用之间可以更改对webservice引用每次handle使用它时都会产生其他结果。 除非我将其设为不可变的否则将阻止引用的更新。 我告诉过你可能会很棘手 是否可以像上一期中使用isImportant setToProcessed和setToFailed方法一样使handle pure 在这种情况下我们必须将WebService作为参数传递就像传递文档列表一样。 我们改变 class FeedHandler {Webservice webserviceListDoc handle(ListDoc changes) {...}} 进入 class FeedHandler {ListDoc handle(ListDoc changes, Webservice webservice) {...}} 在每次调用handle我们都会传递它需要的所有内容需要处理的文档和需要使用的Web服务。 由于此方法不再依赖于FeedHandler类中的任何属性因此我们现在可以使其变为static -将其升级为类级方法。 高阶函数 实际上我们的handle方法刚刚变成了所谓的“高阶函数”即接受一个函数或返回一个函数的函数。 因此回到我最初提出的一个问题 如果我们想要WebService之外的其他东西来创建资源该怎么办 它甚至不应该是Web服务吗 也许我们完全想吃香蕉一只猴子为我们创造资源 class Monkey implements Webservice {OverrideCompletableFutureResource create(Doc doc) {// go bananas! But do create resources plz}
} 看起来很奇怪不是吗 对于抽象提要处理程序的需要 WebService接口太具体了。 任何创造资源的东西都会起作用不是吗 更好的名称是“ ResourceCreator” 因此只需重命名接口即可。 旧 interface Webservice {CompletableFutureResource create(Doc doc)
} 新 interface ResourceCreator {CompletableFutureResource create(Doc doc)
} 具有create方法的ResourceCreator接口 多么合身 现在任何东西都可以实现此接口并且提要处理程序甚至不在乎它是Web服务猴子还是霍比特人。 新方法签名 class FeedHandler {ListDoc handle(ListDoc changes, ResourceCreator creator) {...}} 完美的抽象 功能抽象 在Java中我们将只有一种抽象方法的接口称为功能接口 。 我们的ResourceCreator符合此描述 它只有一个抽象方法create 。 Java的java.util.function程序包具有许多这样的功能接口-它们每个都有一个已定义的目的 Consumer表示一个接受参数且不返回任何值的函数 Supplier表示不接受任何参数的函数仅返回结果 Function表示接受一个参数并返回结果的函数 …和更多 这意味着我们不需要每次都需要一个函数“接受一个参数并返回结果”时就定义一个特定的接口例如ResourceCreator Function已经是一个我们可以利用的接口 这就是Java 8中的Function 简体的样子 interface FunctionT,R {R apply(T t);
} 这就是ResourceCreator现在的样子 interface ResourceCreator {CompletableFutureResource create(Doc doc)
} 您将看到如果满足以下条件我们可以用Function完全替代ResourceCreator 用Doc代替R型 用T型替代CompletableFuture 用方法替代调用create apply 我们可以完全擦除ResourceCreator界面 新方法签名将变为 class FeedHandler {ListDoc handle(ListDoc changes,FunctionDoc, CompletableFutureResource creator) {...}} 我们取得了什么成就 我们现在可以传递任何要handle 函数 该函数需要一个Doc并产生一个CompletableFuture —这就是feed处理程序正常工作所需的全部。 正如您现在可能已经注意到的函数编程处理了很多函数 。 一个函数可以采用另一个函数也可以返回一个函数。 从Java 8开始我们已经准备好了很多功能接口。 每个开发人员都可以以标准化的方式与他们合作因此最好查看它们是否适合您的用例和API并尽可能重用它们。 他们每个人都有泛型类型如T和R可以由你来表明在发生什么什么来的函数的输出 。 现在完整的代码如下所示 class FeedHandler {ListDoc handle(ListDoc changes,FunctionDoc, CompletableFutureResource 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)}} 现在就这样 下次我们将处理故障数据。 如果您有任何意见或建议我很想听听他们的意见 翻译自: https://www.javacodegeeks.com/2018/12/functional-java-functions-parameters.html
