【注】本文译自： Introduction To Pragmatic Functional Java - DZone 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 风格的代码

好的，关键规则看起来不错而且很有用，但是真正的代码会是什么样子呢？
让我们从一个非常典型的后端代码开始：

public interface UserRepository {
    User findById(User.Id userId);
}

public interface UserProfileRepository {
    UserProfile findById(User.Id userId);
}

public class UserService {
    private final UserRepository userRepository;
    private final UserProfileRepository userProfileRepository;

    public UserWithProfile getUserWithProfile(User.Id userId) {
        User user = userRepository.findById(userId);
        if (user == null) {
            throw UserNotFoundException("User with ID " + userId + " not found");
        }
        UserProfile details = userProfileRepository.findById(userId);
        return UserWithProfile.of(user, details == null ? UserProfile.defaultDetails() : details);
    }
}

示例开头的接口是为了上下文清晰而提供的。主要的兴趣点是 getUserWithProfile 方法。我们一步一步来分析。

• 第一条语句从用户存储库中检索 user 变量。
• 由于用户可能不存在于存储库中，因此 user 变量可能为 null。以下 null 检查验证是否是这种情况，如果是，则抛出业务异常。
• 下一步是检索用户配置文件详细信息。缺乏细节不被视为错误。相反，当缺少详细信息时，配置文件将使用默认值。

上面的代码有几个问题。首先，如果存储库中不存在值，则返回 null 从接口看并不明显。 我们需要检查文档，研究实现或猜测这些存储库是如何工作的。
有时使用注解来提供提示，但这仍然不能保证 API 的行为。
为了解决这个问题，让我们将规则应用于存储库：

public interface UserRepository {
    Option<User> findById(User.Id userId);
}

public interface UserProfileRepository {
    Option<UserProfile> findById(User.Id userId);
}

现在无需进行任何猜测 - API 明确告知可能不存在返回值。
现在让我们再看看 getUserWithProfile 方法。 要注意的第二件事是该方法可能会返回一个值或可能会引发异常。这是一个业务异常，因此我们可以应用该规则。更改的主要目标 - 明确方法可能返回值或错误的事实：

public Result<UserWithProfile> getUserWithProfile(User.Id userId) {

好的，现在我们已经清理了 API，可以开始更改代码了。第一个变化是由 userRepository 现在返回
Option<User> 引起的：

public Result<UserWithProfile> getUserWithProfile(User.Id userId) {
    Option<User> user = userRepository.findById(userId);
}

现在我们需要检查用户是否存在，如果不存在，则返回一个错误。使用传统的命令式方法，代码应该是这样的：

public Result<UserWithProfile> getUserWithProfile(User.Id userId) {
    Option<User> user = userRepository.findById(userId);
   
    if (user.isEmpty()) {
        return Result.failure(Causes.cause("User with ID " + userId + " not found"));
    }

}
代码看起来不是很吸引人，但也不比原来的差，所以暂时保持原样。
下一步是尝试转换剩余部分的代码：

public Result<UserWithProfile> getUserWithProfile(User.Id userId) {
    Option<User> user = userRepository.findById(userId);
   
    if (user.isEmpty()) {
        return Result.failure(Causes.cause("User with ID " + userId + " not found"));
    }

    Option<UserProfile> details = userProfileRepository.findById(userId);
   
}

问题来了：详细信息和用户存储在 Option<T> 容器中，因此要组装 UserWithProfile，我们需要以某种方式提取值。这里可能有不同的方法，例如，使用 Option.fold() 方法。生成的代码肯定不会很漂亮，而且很可能会违反规则。
还有另一种方法 - 使用 Option<T> 是具有特殊属性的容器这一事实。
特别是，可以使用 Option.map() 和 Option.flatMap() 方法转换 Option<T> 中的值。此外，我们知道，details 值将由存储库提供或替换为默认值。为此，我们可以使用 Option.or() 方法从容器中提取详细信息。让我们试试这些方法：

public Result<UserWithProfile> getUserWithProfile(User.Id userId) {
    Option<User> user = userRepository.findById(userId);
   
    if (user.isEmpty()) {
        return Result.failure(Causes.cause("User with ID " + userId + " not found"));
    }

    UserProfile details = userProfileRepository.findById(userId).or(UserProfile.defaultDetails());
   
    Option<UserWithProfile> userWithProfile =  user.map(userValue -> UserWithProfile.of(userValue, details));
   
}

现在我们需要编写最后一步 - 将 userWithProfile 容器从 Option<T> 转换为 Result<T>：

public Result<UserWithProfile> getUserWithProfile(User.Id userId) {
    Option<User> user = userRepository.findById(userId);
   
    if (user.isEmpty()) {
        return Result.failure(Causes.cause("User with ID " + userId + " not found"));
    }

    UserProfile details = userProfileRepository.findById(userId).or(UserProfile.defaultDetails());

    Option<UserWithProfile> userWithProfile =  user.map(userValue -> UserWithProfile.of(userValue, details));

    return userWithProfile.toResult(Cause.cause(""));
}

我们暂时将 return 语句中的错误原因留空，然后再次查看代码。
我们可以很容易地发现一个问题：我们肯定知道 userWithProfile 总是存在 - 当 user 不存在时，上面已经处理了这种情况。我们怎样才能解决这个问题？
请注意，我们可以在不检查用户是否存在的情况下调用 user.map()。仅当 user 存在时才会应用转换，否则将被忽略。 这样，我们可以消除 if(user.isEmpty()) 检查。让我们在传递给 user.map() 的 lambda 中移动对 User 的 details 检索和转换到 UserWithProfile 中：

public Result<UserWithProfile> getUserWithProfile(User.Id userId) {
    Option<UserWithProfile> userWithProfile = userRepository.findById(userId).map(userValue -> {
        UserProfile details = userProfileRepository.findById(userId).or(UserProfile.defaultDetails());
        return UserWithProfile.of(userValue, details);
    });
   
    return userWithProfile.toResult(Cause.cause(""));
}

现在需要更改最后一行，因为 userWithProfile 可能会缺失。该错误将与以前的版本相同，因为仅当 userRepository.findById(userId) 返回的值缺失时，userWithProfile 才会缺失：

public Result<UserWithProfile> getUserWithProfile(User.Id userId) {
    Option<UserWithProfile> userWithProfile = userRepository.findById(userId).map(userValue -> {
        UserProfile details = userProfileRepository.findById(userId).or(UserProfile.defaultDetails());
        return UserWithProfile.of(userValue, details);
    });
   
    return userWithProfile.toResult(Causes.cause("User with ID " + userId + " not found"));
}

最后，我们可以内联 details 和 userWithProfile，因为它们仅在创建后立即使用一次：

public Result<UserWithProfile> getUserWithProfile(User.Id userId) {
    return userRepository.findById(userId)
        .map(userValue -> UserWithProfile.of(userValue, userProfileRepository.findById(userId)
                                                                             .or(UserProfile.defaultDetails())))
        .toResult(Causes.cause("User with ID " + userId + " not found"));
}

请注意缩进如何帮助将代码分组为逻辑链接的部分。
让我们来分析结果代码：

• 代码更简洁，为快乐的日子场景编写，没有明确的错误或 null 检查，没有干扰业务逻辑
• 没有简单的方法可以跳过或避免错误或 null 检查，编写正确可靠的代码是直接而自然的。

不太明显的观察：

• 所有类型都是自动派生的。这简化了重构并消除了不必要的混乱。如果需要，仍然可以添加类型。
• 如果在某个时候存储库将开始返回 Result<T> 而不是 Option<T>，代码将保持不变，除了最后一个转换 (toResult) 将被删除。
• 除了用 Option.or() 方法替换三元运算符之外，结果代码看起来很像如果我们将传递给 lambda 内部的原始 return 语句中的代码移动到 map() 方法。

最后一个观察对于开始方便地编写（阅读通常不是问题）PFJ 风格的代码非常有用。它可以改写为以下经验规则：在右侧寻找值。比较一下：

User user = userRepository.findById(userId); // <-- 值在表达式左边

和

return userRepository.findById(userId)
.map(user -> ...); // <-- 值在表达式右边

这种有用的观察有助于从遗留命令式代码风格向 PFJ 转换。

与遗留代码交互

不用说，现有代码不遵循 PFJ 方法。它抛出异常，返回 null 等等。有时可以重新编写此代码以使其与 PFJ 兼容，但通常情况并非如此。对于外部库和框架尤其如此。

调用遗留代码

遗留代码调用有两个主要问题。它们中的每一个都与违反相应的 PFJ 规则有关：

处理业务异常

Result<T> 包含一个名为 lift() 的辅助方法，它涵盖了大多数用例。方法签名看起来是这样：

static <R> Result<R> lift(FN1<? extends Cause, ? super Throwable> exceptionMapper, ThrowingSupplier<R> supplier)

第一个参数是将异常转换为 Cause 实例的函数（反过来，它用于在失败情况下创建 Result<T> 实例）。第二个参数是 lambda，它封装了对需要与 PFJ 兼容的实际代码的调用。
在 Causesutility 类中提供了最简单的函数，它将异常转换为 Cause 的实例：fromThrowable()。它们可以与 Result.lift() 一起使用，如下所示：

public static Result<URI> createURI(String uri) {
    return Result.lift(Causes::fromThrowable, () -> URI.create(uri));
}

处理 null 值返回

这种情况相当简单 - 如果 API 可以返回 null，只需使用 Option.option() 方法将其包装到 Option<T> 中。

提供遗留 API

有时需要允许遗留代码调用以 PFJ 风格编写的代码。特别是，当一些较小的子系统转换为 PFJ 风格时，通常会发生这种情况，但系统的其余部分仍然以旧风格编写，并且需要保留 API。最方便的方法是将实现拆分为两部分——PFJ 风格的 API 和适配器，它只将新 API 适配到旧 API。这可能是一个非常有用的简单辅助方法，如下所示：

public static <T> T unwrap(Result<T> value) {
    return value.fold(
        cause -> { throw new IllegalStateException(cause.message()); },
        content -> content
    );
}

在 Result<T> 中没有提供随时可用的辅助方法，原因如下：

• 可能有不同的用例，并且可以抛出不同类型的异常（已检查和未检查）。
• 将 Cause 转换为不同的特定异常在很大程度上取决于特定的用例。

管理变量作用域

本节将专门介绍在编写 PFJ 风格代码时出现的各种实际案例。
下面的示例假设使用 Result<T>，但这在很大程度上无关紧要，因为所有考虑因素也适用于 Option<T>。此外，示例假定示例中调用的函数被转换为返回 Result<T> 而不是抛出异常。

嵌套作用域

函数风格代码大量使用 lambda 来执行 Option<T> 和 Result<T> 容器内的值的计算和转换。每个 lambda 都隐式地为其参数创建了作用域——它们可以在 lambda 主体内部访问，但不能在其外部访问。
这通常是一个有用的属性，但对于传统的命令式代码，它很不寻常，一开始可能会觉得不方便。幸运的是，有一种简单的技术可以克服感知上的不便。
我们来看看下面的命令式代码：

var value1 = function1(...); // function1()
 可能抛出异常
var value2 = function2(value1, ...); // function2() 可能抛出异常
var value3 = function3(value1, value2, ...); // function3() 可能抛出异常

变量 value1 应该可访问以调用 function2() 和 function3()。 这确实意味着直接转换为 PFJ 样式将不起作用：

function1(...)
.flatMap(value1 -> function2(value1, ...))
.flatMap(value2 -> function3(value1, value2, ...)); // <-- 错, value1 不可访问

为了保持值的可访问性，我们需要使用嵌套作用域，即嵌套调用如下：

function1(...)
.flatMap(value1 -> function2(value1, ...)
    .flatMap(value2 -> function3(value1, value2, ...)));

第二次调用 flatMap() 是针对 function2 返回的值而不是第一个 flatMap() 返回的值。通过这种方式，我们将 value1 保持在范围内，并使 function3 可以访问它。
尽管可以创建任意深度的嵌套作用域，但通常多个嵌套作用域更难阅读和遵循。在这种情况下，强烈建议将更深的范围提取到专用函数中。

平行作用域

另一个经常观察到的情况是需要计算/检索几个独立的值，然后进行调用或构建一个对象。让我们看看下面的例子：

var value1 = function1(...);    // function1() 可能抛出异常
var value2 = function2(...);    // function2() 可能抛出异常
var value3 = function3(...);    // function3() 可能抛出异常
return new MyObject(value1, value2, value3);

乍一看，转换为 PFJ 样式可以与嵌套作用域完全相同。每个值的可见性将与命令式代码相同。不幸的是，这会使范围嵌套很深，尤其是在需要获取许多值的情况下。
对于这种情况，Option<T> 和 Result<T> 提供了一组 all() 方法。这些方法执行所有值的“并行”计算并返回 MapperX<...> 接口的专用版本。 这个接口只有三个方法—— id()、map() 和 flatMap()。map() 和 flatMap() 方法的工作方式与 Option<T> 和 Result<T> 中的相应方法完全相同，只是它们接受具有不同数量参数的 lambda。让我们来看看它在实践中是如何工作的，并将上面的命令式代码转换为 PFJ 样式：

return Result.all(
          function1(...),
          function2(...),
          function3(...)
        ).map(MyObject::new);

除了紧凑和扁平之外，这种方法还有一些优点。首先，它明确表达意图——在使用前计算所有值。命令式代码按顺序执行此操作，隐藏了原始意图。第二个优点 - 每个值的计算是独立的，不会将不必要的值带入范围。这减少了理解和推理每个函数调用所需的上下文。

替代作用域

一个不太常见但仍然很重要的情况是我们需要检索一个值，但如果它不可用，那么我们使用该值的替代来源。当有多个替代方案可用时，这种情况的频率甚至更低，而且在涉及错误处理时会更加痛苦。
我们来看看下面的命令式代码：

MyType value;

try {
    value = function1(...);
} catch (MyException e1) {
    try {
        value = function2(...);    
    } catch(MyException e2) {
        try {
            value = function3(...);
        } catch(MyException e3) {
            ... // repeat as many times as there are alternatives
        }
    }
}

代码是人为设计的，因为嵌套案例通常隐藏在其他方法中。尽管如此，整体逻辑并不简单，主要是因为除了选择值之外，我们还需要处理错误。错误处理使代码变得混乱，并使初始意图 - 选择第一个可用的替代方案 - 隐藏在错误处理中。
转变为 PFJ 风格使意图非常清晰：

var value = Result.any(
        function1(...),
        function2(...),
        function3(...)
    );

不幸的是，这里有一个重要的区别：原始命令式代码仅在必要时计算第二个和后续替代项。在某些情况下，这不是问题，但在许多情况下，这是非常不可取的。幸运的是，Result.any() 有一个惰性版本。使用它，我们可以重写代码如下：

var value = Result.any(
        function1(...),
        () -> function2(...),
        () -> function3(...)
    );

现在，转换后的代码的行为与它的命令式对应代码完全一样。

Option<T> 和 Result<T> 的简要技术概述

这两个容器在函数式编程术语中是单子（monad）。
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> 有以下副作用的方法：

Option<T> whenPresent(Consumer<? super T> consumer);
Option<T> whenEmpty(Runnable action);
Option<T> apply(Runnable emptyValConsumer, Consumer<? super T> nonEmptyValConsumer);

Result<T> 有以下副作用的方法：

Result<T> onSuccess(Consumer<T> consumer);
Result<T> onSuccessDo(Runnable action);
Result<T> onFailure(Consumer<? super Cause> consumer);
Result<T> onFailureDo(Runnable action);
Result<T> apply(Consumer<? super Cause> failureConsumer, Consumer<? super T> successConsumer);

这些方法向读者提供了代码处理副作用而不是转换的提示。

其他有用的工具

除了 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 专注于清晰表达意图并减少心理负担