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

发表回复

您的电子邮箱地址不会被公开。