实用函数式 Java (PFJ)简介
【注】本文译自: https://dzone.com/articles/introduction-to-pragmatic-functional-java
实用函数式(Pragmatic Funcational) Java 是一种基于函数式编程概念的现代、非常简洁但可读的 Java 编码风格。
实用函数式 Java (PFJ) 试图定义一种新的惯用 Java 编码风格。编码风格,将完全利用当前和即将推出的 Java 版本的所有功能,并涉及编译器来帮助编写简洁但可靠和可读的代码。
虽然这种风格甚至可以在 Java 8 中使用,但在 Java 11 中它看起来更加简洁和简洁。它在 Java 17 中变得更具表现力,并受益于每个新的 Java 语言功能。
但 PFJ 不是免费的午餐,它需要开发人员的习惯和方法发生重大改变。改变习惯并不容易,传统的命令式习惯尤其难以解决。
这值得么? 确实! PFJ 代码简洁、富有表现力且可靠。它易于阅读和维护,并且在大多数情况下,如果代码可以编译 - 它可以工作!
实用函数式 Java 的元素
PFJ 源自一本精彩的 Effective Java 书籍,其中包含一些额外的概念和约定,特别是源自函数式编程(FP:Functional Programming)。请注意,尽管使用了 FP 概念,但 PFJ 并未尝试强制执行特定于 FP 的术语。(尽管对于那些有兴趣进一步探索这些概念的人,我们也提供了参考)。
PFJ 专注于:
减轻心理负担。
提高代码可靠性。
提高长期可维护性。
借助编译器来帮助编写正确的代码。
让编写正确的代码变得简单而自然,编写不正确的代码虽然仍然可能,但应该需要付出努力。
尽管目标雄心勃勃,但只有两个关键的 PFJ 规则:
尽可能避免 null。
没有业务异常。
下面,更详细地探讨了每个关键规则:
尽可能避免 null(ANAMAP 规则)
变量的可空性是特殊状态之一。它们是众所周知的运行时错误和样板代码的来源。为了消除这些问题并表示可能丢失的值,PFJ 使用 Option<T> 容器。这涵盖了可能出现此类值的所有情况 - 返回值、输入参数或字段。
在某些情况下,例如出于性能或与现有框架兼容性的原因,类可能会在内部使用 null。这些情况必须清楚记录并且对类用户不可见,即所有类 API 都应使用 Option<T>.。
这种方法有几个优点:
可空变量在代码中立即可见。无需阅读文档、检查源代码或依赖注释。
编译器区分可为空和不可为空的变量,并防止它们之间的错误赋值。
消除了 null 检查所需的所有样板。
无业务异常(NBE 规则)
PFJ 仅使用异常来表示致命的、不可恢复的(技术)故障的情况。此类异常可能仅出于记录和/或正常关闭应用程序的目的而被拦截。不鼓励并尽可能避免所有其他异常及其拦截。
业务异常是特殊状态的另一种情况。为了传播和处理业务级错误,PFJ 使用 Result<T> 容器。同样,这涵盖了可能出现错误的所有情况 - 返回值、输入参数或字段。实践表明,字段很少(如果有的话)需要使用这个容器。
没有任何正当的情况可以使用业务级异常。与通过专用包装方法与现有 Java 库和遗留代码交互。Result<T> 容器包含这些包装方法的实现。
无业务异常规则具有以下优点:
可以返回错误的方法在代码中立即可见。 无需阅读 文档、检查源代码或分析调用树,以检查可以抛出哪些异常以及在哪些条件下被抛出。
编译器强制执行正确的错误处理和传播。
几乎没有错误处理和传播的样板。
我们可以为快乐的日子场景编写代码,并在最方便的点处理错误 - 异常的原始意图,这一点实际上从未实现过。
代码保持可组合、易于阅读和推理,在执行流程中没有隐藏的中断或意外的转换——你读到的就是将要执行的。
将遗留代码转换为 PFJ 风格的代码
好的,关键规则看起来不错而且很有用,但是真正的代码会是什么样子呢?
让我们从一个非常典型的后端代码开始:
示例开头的接口是为了上下文清晰而提供的。主要的兴趣点是 getUserWithProfile 方法。我们一步一步来分析。
第一条语句从用户存储库中检索 user 变量。
由于用户可能不存在于存储库中,因此 user 变量可能为 null。以下 null 检查验证是否是这种情况,如果是,则抛出业务异常。
下一步是检索用户配置文件详细信息。缺乏细节不被视为错误。相反,当缺少详细信息时,配置文件将使用默认值。
上面的代码有几个问题。首先,如果存储库中不存在值,则返回 null 从接口看并不明显。 我们需要检查文档,研究实现或猜测这些存储库是如何工作的。
有时使用注解来提供提示,但这仍然不能保证 API 的行为。
为了解决这个问题,让我们将规则应用于存储库:
现在无需进行任何猜测 - API 明确告知可能不存在返回值。
现在让我们再看看 getUserWithProfile 方法。 要注意的第二件事是该方法可能会返回一个值或可能会引发异常。这是一个业务异常,因此我们可以应用该规则。更改的主要目标 - 明确方法可能返回值或错误的事实:
好的,现在我们已经清理了 API,可以开始更改代码了。第一个变化是由 userRepository 现在返回 Option<User> 引起的:
现在我们需要检查用户是否存在,如果不存在,则返回一个错误。使用传统的命令式方法,代码应该是这样的:
代码看起来不是很吸引人,但也不比原来的差,所以暂时保持原样。
下一步是尝试转换剩余部分的代码:
问题来了:详细信息和用户存储在 Option<T> 容器中,因此要组装 UserWithProfile,我们需要以某种方式提取值。这里可能有不同的方法,例如,使用 Option.fold() 方法。生成的代码肯定不会很漂亮,而且很可能会违反规则。
还有另一种方法 - 使用 Option<T> 是具有特殊属性的容器这一事实。
特别是,可以使用 Option.map() 和 Option.flatMap()方法转换 Option<T> 中的值。此外,我们知道,details 值将由存储库提供或替换为默认值。为此,我们可以使用 Option.or() 方法从容器中提取详细信息。让我们试试这些方法:
现在我们需要编写最后一步 - 将 userWithProfile 容器从 Option<T> 转换为 Result<T>:
我们暂时将 return 语句中的错误原因留空,然后再次查看代码。
我们可以很容易地发现一个问题:我们肯定知道 userWithProfile 总是存在 - 当 user 不存在时,上面已经处理了这种情况。我们怎样才能解决这个问题?
请注意,我们可以在不检查用户是否存在的情况下调用 user.map()。仅当 user 存在时才会应用转换,否则将被忽略。 这样,我们可以消除 if(user.isEmpty()) 检查。让我们在传递给 user.map() 的 lambda 中移动对 User 的 details 检索和转换到 UserWithProfile 中:
现在需要更改最后一行,因为 userWithProfile 可能会缺失。该错误将与以前的版本相同,因为仅当 userRepository.findById(userId) 返回的值缺失时,userWithProfile 才会缺失:
最后,我们可以内联 details 和 userWithProfile,因为它们仅在创建后立即使用一次:
请注意缩进如何帮助将代码分组为逻辑链接的部分。
让我们来分析结果代码:
代码更简洁,为快乐的日子场景编写,没有明确的错误或 null 检查,没有干扰业务逻辑
没有简单的方法可以跳过或避免错误或 null 检查,编写正确可靠的代码是直接而自然的。
不太明显的观察:
所有类型都是自动派生的。这简化了重构并消除了不必要的混乱。如果需要,仍然可以添加类型。
如果在某个时候存储库将开始返回 Result<T> 而不是 Option<T>,代码将保持不变,除了最后一个转换 (toResult) 将被删除。
除了用 Option.or() 方法替换三元运算符之外,结果代码看起来很像如果我们将传递给 lambda 内部的原始 return 语句中的代码移动到 map() 方法。
最后一个观察对于开始方便地编写(阅读通常不是问题)PFJ 风格的代码非常有用。它可以改写为以下经验规则:在右侧寻找值。比较一下:
和
这种有用的观察有助于从遗留命令式代码风格向 PFJ 转换。
与遗留代码交互
不用说,现有代码不遵循 PFJ 方法。它抛出异常,返回 null 等等。有时可以重新编写此代码以使其与 PFJ 兼容,但通常情况并非如此。对于外部库和框架尤其如此。
调用遗留代码
遗留代码调用有两个主要问题。它们中的每一个都与违反相应的 PFJ 规则有关:
处理业务异常
Result<T> 包含一个名为 lift() 的辅助方法,它涵盖了大多数用例。方法签名看起来是这样:
第一个参数是将异常转换为 Cause 实例的函数(反过来,它用于在失败情况下创建 Result<T> 实例)。第二个参数是 lambda,它封装了对需要与 PFJ 兼容的实际代码的调用。
在 Causesutility 类中提供了最简单的函数,它将异常转换为 Cause 的实例:fromThrowable()。它们可以与 Result.lift() 一起使用,如下所示:
处理 null 值返回
这种情况相当简单 - 如果 API 可以返回 null,只需使用 Option.option() 方法将其包装到 Option<T> 中。
提供遗留 API
有时需要允许遗留代码调用以 PFJ 风格编写的代码。特别是,当一些较小的子系统转换为 PFJ 风格时,通常会发生这种情况,但系统的其余部分仍然以旧风格编写,并且需要保留 API。最方便的方法是将实现拆分为两部分——PFJ 风格的 API 和适配器,它只将新 API 适配到旧 API。这可能是一个非常有用的简单辅助方法,如下所示:
在 Result<T> 中没有提供随时可用的辅助方法,原因如下:
可能有不同的用例,并且可以抛出不同类型的异常(已检查和未检查)。
将 Cause 转换为不同的特定异常在很大程度上取决于特定的用例。
管理变量作用域
本节将专门介绍在编写 PFJ 风格代码时出现的各种实际案例。
下面的示例假设使用 Result<T>,但这在很大程度上无关紧要,因为所有考虑因素也适用于 Option<T>。此外,示例假定示例中调用的函数被转换为返回 Result<T> 而不是抛出异常。
嵌套作用域
函数风格代码大量使用 lambda 来执行 Option<T> 和 Result<T> 容器内的值的计算和转换。每个 lambda 都隐式地为其参数创建了作用域——它们可以在 lambda 主体内部访问,但不能在其外部访问。
这通常是一个有用的属性,但对于传统的命令式代码,它很不寻常,一开始可能会觉得不方便。幸运的是,有一种简单的技术可以克服感知上的不便。
我们来看看下面的命令式代码:
变量 value1 应该可访问以调用 function2() 和 function3()。 这确实意味着直接转换为 PFJ 样式将不起作用:
为了保持值的可访问性,我们需要使用嵌套作用域,即嵌套调用如下:
第二次调用 flatMap() 是针对 function2 返回的值而不是第一个 flatMap(). 返回的值。通过这种方式,我们将 value1 保持在范围内,并使 function3 可以访问它。
尽管可以创建任意深度的嵌套作用域,但通常多个嵌套作用域更难阅读和遵循。在这种情况下,强烈建议将更深的范围提取到专用函数中。
平行作用域
另一个经常观察到的情况是需要计算/检索几个独立的值,然后进行调用或构建一个对象。让我们看看下面的例子:
乍一看,转换为 PFJ 样式可以与嵌套作用域完全相同。每个值的可见性将与命令式代码相同。不幸的是,这会使范围嵌套很深,尤其是在需要获取许多值的情况下。
对于这种情况,Option<T> 和 Result<T> 提供了一组 all() 方法。这些方法执行所有值的“并行”计算并返回 MapperX<...> 接口的专用版本。 这个接口只有三个方法—— id()、map() 和 flatMap()。map() 和 flatMap() 方法的工作方式与 Option<T> 和 Result<T> 中的相应方法完全相同,只是它们接受具有不同数量参数的 lambda。让我们来看看它在实践中是如何工作的,并将上面的命令式代码转换为 PFJ 样式:
除了紧凑和扁平之外,这种方法还有一些优点。首先,它明确表达意图——在使用前计算所有值。命令式代码按顺序执行此操作,隐藏了原始意图。第二个优点 - 每个值的计算是独立的,不会将不必要的值带入范围。这减少了理解和推理每个函数调用所需的上下文。
替代作用域
一个不太常见但仍然很重要的情况是我们需要检索一个值,但如果它不可用,那么我们使用该值的替代来源。当有多个替代方案可用时,这种情况的频率甚至更低,而且在涉及错误处理时会更加痛苦。
我们来看看下面的命令式代码:
代码是人为设计的,因为嵌套案例通常隐藏在其他方法中。尽管如此,整体逻辑并不简单,主要是因为除了选择值之外,我们还需要处理错误。错误处理使代码变得混乱,并使初始意图 - 选择第一个可用的替代方案 - 隐藏在错误处理中。
转变为 PFJ 风格使意图非常清晰:
不幸的是,这里有一个重要的区别:原始命令式代码仅在必要时计算第二个和后续替代项。在某些情况下,这不是问题,但在许多情况下,这是非常不可取的。幸运的是,Result.any() 有一个惰性版本。使用它,我们可以重写代码如下:
现在,转换后的代码的行为与它的命令式对应代码完全一样。
Option<T> 和 Result<T> 的简要技术概述
Option<T> 是 Option/Optional/Maybe monad 的直接实现。
Result<T> 是 Either<L,R> 的特意简化和专门版本:左类型是固定的,应该实现 Cause 接口。专业化使 API 与 Option<T> 非常相似,并以失去通用性为代价消除了许多不必要的输入。
这个特定的实现集中在两件事上:
与现有 JDK 类(如 Optional<T> 和 Stream<T>)之间的互操作性
用于明确意图表达的 API
最后一句话值得更深入的解释。
每个容器都有几个核心方法:
工厂方法
map() 转换方法,转换值但不改变特殊状态:present Option<T> 保持 present,success Result<T> 保持 success。
flatMap() 转换方法,除了转换之外,还可以改变特殊状态:将 Option<T> present 转换为 empty 或将 Result<T> success 转换为 failure。
fold() 方法,它同时处理两种情况(Option<T> 的 present/empty 和 Result<T> 的 success/failure)。
除了核心方法,还有一堆辅助方法,它们在经常观察到的用例中很有用。
在这些方法中,有一组方法是明确设计来产生副作用的。
Option<T> 有以下副作用的方法:
Result<T> 有以下副作用的方法:
这些方法向读者提供了代码处理副作用而不是转换的提示。
其他有用的工具
除了 Option<T> 和 Result<T> 之外,PFJ 还使用了一些其他通用类。下面,将对每种方法进行更详细地描述。
Functions(函数)
JDK 提供了许多有用的功能接口。不幸的是,通用函数的函数式接口仅限于两个版本:单参数 Function<T, R> 和两个参数 BiFunction<T, U, R>。
显然,这在许多实际情况中是不够的。此外,出于某种原因,这些函数的类型参数与 Java 中函数的声明方式相反:结果类型列在最后,而在函数声明中,它首先定义。
PFJ 为具有 1 到 9 个参数的函数使用一组一致的函数接口。 为简洁起见,它们被称为 FN1…FN9。到目前为止,还没有更多参数的函数用例(通常这是代码异味)。但如果有必要,该清单可以进一步扩展。
Tuples(元组)
元组是一种特殊的容器,可用于在单个变量中存储多个不同类型的值。与类或记录不同,存储在其中的值没有名称。这使它们成为在保留类型的同时捕获任意值集的不可或缺的工具。这个用例的一个很好的例子是 Result.all() 和 Option.all() 方法集的实现。
在某种意义上,元组可以被认为是为函数调用准备的一组冻结的参数。从这个角度来看,让元组内部值只能通过 map() 方法访问的决定听起来很合理。然而,具有 2 个参数的元组具有额外的访问器,可以使用 Tuple2<T1,T2> 作为各种 Pair<T1,T2> 实现的替代。
PFJ 使用一组一致的元组实现,具有 0 到 9 个值。提供具有 0 和 1 值的元组以保持一致性。
结论
实用函数式 Java 是一种基于函数式编程概念的现代、非常简洁但可读的 Java 编码风格。与传统的惯用 Java 编码风格相比,它提供了许多好处:
PFJ 借助 Java 编译器来帮助编写可靠的代码:
编译的代码通常是有效的
许多错误从运行时转移到编译时
某些类别的错误,例如 NullPointerException 或未处理的异常,实际上已被消除
PFJ 显着减少了与错误传播和处理以及 null 检查相关的样板代码量
PFJ 专注于清晰表达意图并减少心理负担
版权声明: 本文为 InfoQ 作者【信码由缰】的原创文章。
原文链接:【http://xie.infoq.cn/article/b85f1b1bf9722411c242570ac】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论