如何在Java中将 this 传递给 Supplier

在Java 8 引入了函数式接口后，Supplier 接口变得非常常用，它代表一个无参数的函数，返回一个结果。在某些场景下，我们可能需要将当前对象 this 传递给一个 Supplier。本文将探讨几种实现方式，并分析它们的优劣。

问题背景与需求

假设我们有一个类 Thing，它包含一个值和一个 CompletableFuture。CompletableFuture 的完成依赖于其他组件的状态。我们希望使用 completeAsync() 方法来异步地完成 CompletableFuture，并将 this 对象传递给 Supplier。

import java.util.concurrent.CompletableFuture;
import java.util.function.Supplier;

class Thing {
    final T value;
    final CompletableFuture future;

    Thing(T value) {
        this.value = value;
        this.future = new CompletableFuture<>();
    }

    Thing self() {
        return this;
    }

    void reject() {
        future.cancel(false);
    }

    void complete() {
        // 方式一：使用 Lambda 表达式
        future.completeAsync(() -> this);

        // 方式二：使用方法引用
        future.completeAsync(this::self);
    }
}

在上述代码中，我们使用了两种方式将 this 传递给 Supplier：

立即学习“Java免费学习笔记（深入）”；

1. Lambda 表达式: () -> this 创建了一个匿名函数，返回 this 对象。
2. 方法引用: this::self 引用了 self() 方法，该方法直接返回 this 对象。

Lambda 表达式 vs. 方法引用

这两种方式都能达到将 this 传递给 Supplier 的目的，但它们之间存在细微的差异。

Digram

让Figma更好用的AI神器

下载

• 可读性: 方法引用通常被认为更简洁，更易于阅读，因为它直接表达了“返回 this”的意图。
• 性能: 在某些情况下，方法引用可能比 Lambda 表达式略微高效。Lambda 表达式会在每次调用时创建一个新的匿名类实例，而方法引用则可以避免这种额外的对象分配。然而，现代 JVM 对 Lambda 表达式的优化已经相当成熟，这种性能差异通常可以忽略不计。
• 维护性: 如果 self() 方法的实现发生变化（例如，添加了额外的逻辑），使用方法引用的代码会自动反映这些变化。而使用 Lambda 表达式的代码则需要手动更新。

最佳实践与注意事项

虽然上述两种方式都能实现将 this 传递给 Supplier 的目的，但在大多数情况下，直接在需要 this 的地方使用 this 即可。

例如，如果 CompletableFuture 完成后需要访问 Thing 对象的其他字段，可以直接在 Lambda 表达式或 self() 方法中访问 this.value 或调用 this.otherMethod()。

class Thing {
    final T value;
    final CompletableFuture future;

    Thing(T value) {
        this.value = value;
        this.future = new CompletableFuture<>();
    }

    void complete() {
        future.completeAsync(() -> {
            // 直接访问 this.value
            System.out.println("Value: " + this.value);
            return this;
        });
    }
}

总结

将 this 传递给 Supplier 可以通过 Lambda 表达式或方法引用实现。方法引用通常更简洁、可读性更强，并且可能略微高效。然而，在大多数情况下，直接在需要 this 的地方使用 this 即可，避免不必要的复杂性。选择哪种方式取决于具体的场景和个人偏好。 关键在于保持代码的清晰性和可维护性。