Java 设计模式 Monads 的美丽世界

让我从免责声明开始。从函数式编程的角度来看，下面的解释绝不是精确的或绝对准确的。相反，我将重点解释的清晰和简单性上，以便让尽可能多的 Java 开发人员进入这个美丽的世界。

几年前，当我开始深入研究函数式编程时，我很快发现有大量的信息，但对于几乎完全具有命令式背景的普通 Java 开发人员来说，几乎无法理解。如今，情况正在慢慢改变。例如，有很多文章解释了例如基本的 FP 概念（参考： 实用函数式 Java （PFJ）简介）以及它们如何适用于 Java。或解释如何正确使用 Java 流的文章。但是 Monads 仍然不在这些文章的重点之外。我不知道为什么会发生这种情况，但我会努力填补这个空白。

那么，Monad 是什么？

Monad 是……一种设计模式。就这么简单。这种设计模式由两部分组成：

• Monad 是一个值的容器。对于每个 Monad，都有一些方法可以将值包装到 Monad 中。
• Monad 为内部包含的值实现了“控制反转”。为了实现这一点，Monad 提供了接受函数的方法。这些函数接受与 Monad 中存储的类型相同的值，并返回转换后的值。转换后的值被包装到与源值相同的 Monad 中。
  为了理解模式的第二部分，我们可以看看 Monad 的接口：

interface Monad<T> {
    <R> Monad<R> map(Function<T, R> mapper);

    <R> Monad<R> flatMap(Function<T, Monad<R>> mapper);
}

当然，特定的 Monad 通常有更丰富的接口，但这两个方法绝对应该存在。

乍一看，接受函数而不是访问值并没有太大区别。事实上，这使 Monad 能够完全控制如何以及何时应用转换功能。当您调用 getter 时，您希望立即获得值。在 Monad 转换的情况下可以立即应用或根本不应用，或者它的应用可以延迟。缺乏对内部值的直接访问使 monad 能够表示甚至尚不可用的值！

下面我将展示一些 Monad 的例子以及它们可以解决哪些问题。

Monad 缺失值或 Optional/Maybe 的场景

这个 Monad 有很多名字——Maybe、Option、Optional。最后一个听起来很熟悉，不是吗？ 好吧，因为 Java 8 Optional 是 Java 平台的一部分。

不幸的是，Java Optional 实现过于尊崇传统的命令式方法，这使得它的用处不大。特别是 Optional 允许应用程序使用 .get() 方法获取值。如果缺少值，甚至会抛出 NPE。因此，Optional 的用法通常仅限于表示返回潜在的缺失值，尽管这只是潜在用法的一小部分。

也许 Monad 的目的是表示可能会丢失的值。传统上，Java 中的这个角色是为 null 保留的。不幸的是，这会导致许多不同的问题，包括著名的 NullPointerException。

例如，如果您期望某些参数或某些返回值可以为 null，则应该在使用前检查它：

public UserProfileResponse getUserProfileHandler(final User.Id userId) {
    final User user = userService.findById(userId);
    if (user == null) {
    return UserProfileResponse.error(USER_NOT_FOUND);
    }
   
    final UserProfileDetails details = userProfileService.findById(userId);
   
    if (details == null) {
    return UserProfileResponse.of(user, UserProfileDetails.defaultDetails());
    }
   
    return UserProfileResponse.of(user, details);
}

看起来熟悉吗？当然了。

让我们看看 Option Monad 如何改变这一点（为简洁起见，使用一个静态导入）：

    public UserProfileResponse getUserProfileHandler(final User.Id userId) {
        return ofNullable(userService.findById(userId))
                .map(user -> UserProfileResponse.of(user,
                        ofNullable(userProfileService.findById(userId)).orElseGet(UserProfileDetails::defaultDetails)))
                .orElseGet(() -> UserProfileResponse.error(USER_NOT_FOUND));
    }

请注意，代码更加简洁，对业务逻辑的“干扰”也更少。

这个例子展示了 monadic 的“控制反转”是多么方便：转换不需要检查 null，只有当值实际可用时才会调用它们。

“如果/当值可用时做某事”是开始方便地使用 Monads 的关键心态。

请注意，上面的示例保留了原始 API 的完整内容。但是更广泛地使用该方法并更改 API 是有意义的，因此它们将返回 Optional 而不是 null：

    public Optional<UserProfileResponse> getUserProfileHandler4(final User.Id userId) {
        return optionalUserService.findById(userId).flatMap(
                user -> userProfileService.findById(userId).map(profile -> UserProfileResponse.of(user, profile)));
    }

一些观察：

• 代码更简洁，包含几乎零样板。
• 所有类型都是自动派生的。虽然并非总是如此，但在绝大多数情况下，类型是由编译器派生的---尽管与 Scala 相比，Java 中的类型推断较弱。
• 没有明确的错误处理，而是我们可以专注于“快乐日子场景”。
• 所有转换都方便地组合和链接，不会中断或干扰主要业务逻辑。
  事实上，上面的属性对于所有的 Monad 都是通用的。

抛还是不抛是个问题

事情并不总是如我们所愿，我们的应用程序生活在现实世界中，充满痛苦、错误和失误。有时我们可以和他们一起做点什么，有时不能。如果我们不能做任何事情，我们至少希望通知调用者事情并不像我们预期的那样进行。

在 Java 中，我们传统上有两种机制来通知调用者问题：

• 返回特殊值（通常为空）
• 抛出异常
  除了返回 null 我们还可以返回 Option Monad（见上文），但这通常是不够的，因为需要更多关于错误的详细信息。通常在这种情况下我们会抛出异常。

但是这种方法有一个问题。事实上，甚至很少有问题。

• 异常中断执行流程
• 异常增加了很多心理开销
  异常引起的心理开销取决于异常的类型：
• 检查异常迫使你要么在这里处理它们，要么在签名中声明它们并将麻烦转移到调用者身上
• 未经检查的异常会导致相同级别的问题，但编译器不支持
  不知道哪个更差。

Either Monad 来了

让我们先分析一下这个问题。我们想要返回的是一些特殊值，它可以是两种可能的事情之一：结果值（成功时）或错误（失败时）。请注意，这些东西是相互排斥的——如果我们返回值，则不需要携带错误，反之亦然。

以上是对Either Monad 的几乎准确描述：任何给定的实例都只包含一个值，并且该值具有两种可能类型之一。

任何 Monad 的接口都可以这样描述：

interface Either<L, R> {
    <T> Either<T, R> mapLeft(Function<L, T> mapper);

    <T> Either<T, R> flatMapLeft(Function<L, Either<T, R>> mapper);

    <T> Either<L, T> mapLeft(Function<T, R> mapper);

    <T> Either<L, T> flatMapLeft(Function<R, Either<L, T>> mapper);
}

该接口相当冗长，因为它在左右值方面是对称的。对于更窄的用例，当我们需要传递成功或错误时，这意味着我们需要就某种约定达成一致——哪种类型（第一种或第二种）将保存错误，哪种将保存值。

在这种情况下，Either 的对称性质使其更容易出错，因为很容易无意中交换代码中的错误和成功值。

虽然这个问题很可能会被编译器捕获，但最好为这个特定用例量身定制。如果我们修复其中一种类型，就可以做到这一点。显然，修复错误类型更方便，因为 Java 程序员已经习惯于从单个 Throwable 类型派生所有错误和异常。

Result Monad — 专门用于错误处理和传播的 Either Monad

所以，让我们假设所有错误都实现相同的接口，我们称之为失败。现在我们可以简化和减少接口：

interface Result<T> {
    <R> Result<R> map(Function<T, R> mapper);

    <R> Result<R> flatMap(Function<T, Result<R>> mapper);
}

Result Monad API 看起来与 Maybe Monad 的 API 非常相似。

使用这个 Monad，我们可以重写前面的例子：

    public Result<UserProfileResponse> getUserProfileHandler(final User.Id userId) {
        return resultUserService.findById(userId).flatMap(user -> resultUserProfileService.findById(userId)
                .map(profile -> UserProfileResponse.of(user, profile)));
    }

好吧，它与上面的示例基本相同，唯一的变化是 Monad — Result 而不是 Optional。与前面的例子不同，我们有关于错误的完整信息，所以我们可以在上层做一些事情。但是，尽管完整的错误处理代码仍然很简单并且专注于业务逻辑。

“承诺是一个很重要的词。它要么成就了什么，要么破坏了什么。”

我想展示的下一个 Monad 将是 Promise Monad。

必须承认，对于 Promise 是否是 monad，我还没有找到权威的答案。不同的作者对此有不同的看法。我纯粹是从实用的角度来看它的：它的外观和行为与其他 monad 非常相似，所以我认为它们是一个 monad。

Promise Monad 代表一个（可能还不可用的）值。从某种意义上说，它与 Maybe Monad 非常相似。

Promise Monad 可用于表示譬如对外部服务或数据库的请求结果、文件读取或写入等。基本上它可以表示任何需要 I/O 和时间来执行它的东西。Promise 支持与我们在其他 Monad 中观察到的相同的思维方式——“如果/当价值可用时做某事”。

请注意，由于无法预测操作是否成功，因此让 Promise 表示的不是 value 本身而是 Result 内部带有 value 是很方便的。

要了解它是如何工作的，让我们看一下下面的示例：

...
public interface ArticleService {
    // Returns list of articles for specified topics posted by specified users
    Promise<Collection<Article>> userFeed(final Collection<Topic.Id> topics, final Collection<User.Id> users);
}
...
public interface TopicService {
    // Returns list of topics created by user
    Promise<Collection<Topic>> topicsByUser(final User.Id userId, final Order order);
}
...
public class UserTopicHandler {
    private final ArticleService articleService;
    private final TopicService topicService;

    public UserTopicHandler(final ArticleService articleService, final TopicService topicService) {
        this.articleService = articleService;
        this.topicService = topicService;
    }

    public Promise<Collection<Article>> userTopicHandler(final User.Id userId) {
        return topicService.topicsByUser(userId, Order.ANY)
                .flatMap(topicsList -> articleService.articlesByUserTopics(userId, topicsList.map(Topic::id)));
    }
}

为了提供整个上下文，我包含了两个必要的接口，但实际上有趣的部分是 userTopicHandler() 方法。尽管这种方法的简单性令人怀疑：

• 调用 TopicService 并检索由提供的用户创建的主题列表
• 成功获取主题列表后，该方法提取主题 ID，然后调用 ArticleService，获取用户为指定主题创建的文章列表

• 执行端到端的错误处理

  后记

  Monads 是非常强大和方便的工具。使用“当价值可用时做”的思维方式编写代码需要一些时间来习惯，但是一旦你开始使用它，它将让你的生活变得更加简单。它允许将大量的心理开销卸载给编译器，并使许多错误在编译时而不是在运行时变得不可能或可检测到。

---

本文译自：[Beautiful World of Monads - DEV Community](
https://dev.to/siy/beautiful-...)