如何用Vavr以函数式风格正确实现指定代码？求最佳实践建议

让我们一步步拆解你的问题，先梳理现有代码的情况，再分析你的实现是否正确，最后给出更清晰的Vavr函数式方案：

现有代码回顾 #

原命令式代码 #

private Option<CalcResult> calculate(Integer X, Integer Y) {
    if (X < Y) return Option.none();
    return Option.of(X + Y);
}

public Option<CalcResult> otherMethod(Obj o) {
    if (o.getAttr()) {
        // getA() & getB()是不受控制的API，可能返回null
        if (o.getA() != null && o.getB() != null) {
            return calculate(o.getA(), o.getB());
        }
    }
    return Option.none();
}

已优化的calculate方法 #

你已经把calculate改成了更简洁的函数式风格，这一步做得很好：

private Option<CalcResult> calculate(Integer X, Integer Y) {
    return Option.when(X > Y, () -> X + Y);
}

你尝试的两种otherMethod实现 #

第一种（可读性差）

public Option<CalcResult> otherMethod(Obj o) {
    return Option.when(o.getAttr(), () -> 
        For(Option.of(o.getA()), Option.of(o.getB()))
            .yield(this::calculate)
            .toOption()
            .flatMap(Function.identity())
    ).flatMap(Function.identity());
}

第二种（可读性提升但存在问题）

public Option<CalcResult> otherMethod(Obj o) {
    return For(
        Option.when(o.getAttr(), o::getAttr()),
        Option.of(o.getA()),
        Option.of(o.getB())
    )
    .yield((__, x, y) -> this.calculate(x, y))
    .toOption()
    .flatMap(Function.identity());
}

你的For-comprehension使用是否正确？ #

第二种实现的核心问题出在Option.when(o.getAttr(), o::getAttr())这一行：

• Option.when的第二个参数是Supplier<T>，你这里传入的o::getAttr会返回Boolean，所以这行代码实际生成的是Option<Boolean>，而不是你想要的“仅当o.getAttr()为true时允许后续流程”的信号。
• For-comprehension会尝试展开这个Option<Boolean>，但你其实不需要这个布尔值，只是需要一个条件判断：当o.getAttr()为false时直接返回none。

所以这个实现逻辑上是有问题的，虽然可读性比第一种好，但不符合你的需求。

推荐的函数式实现方案 #

这里提供几种更清晰、符合Vavr最佳实践的方案：

方案一：链式调用（最简洁直观） #

利用Vavr Option的链式操作，先处理前置条件，再组合getA()和getB()的结果：

public Option<CalcResult> otherMethod(Obj o) {
    return Option.when(o.getAttr(), () -> o)
                 .flatMap(obj -> Option.of(obj.getA())
                                       .flatMap(a -> Option.of(obj.getB())
                                                           .flatMap(b -> calculate(a, b))));
}

• 第一步：Option.when(o.getAttr(), () -> o)：当o.getAttr()为true时返回Option.of(o)，否则返回none，直接终止流程。
• 后续通过flatMap逐层处理getA()和getB()的null情况，最后调用calculate。

方案二：正确使用For-comprehension #

如果偏好For-comprehension的写法，需要把前置条件转为一个“占位”的Option（比如用Unit类型表示条件满足），再组合其他Option：

import io.vavr.control.Option;
import static io.vavr.API.For;
import static io.vavr.API.Option;

public Option<CalcResult> otherMethod(Obj o) {
    return For(
            Option.when(o.getAttr(), () -> ()), // 条件满足时返回空Unit，否则none
            Option.of(o.getA()),
            Option.of(o.getB())
        )
        .yield((__, a, b) -> calculate(a, b))
        .toOption()
        .flatMap(Function.identity()); // 展开嵌套的Option<Option<CalcResult>>
}

• 第一个Option.when生成Option<Void>，仅当条件满足时存在值，作为For-comprehension的“开关”。
• yield返回的是Option<CalcResult>，所以toOption()会得到Option<Option<CalcResult>>，最后用flatMap展开成单层的Option<CalcResult>。

方案三：用zip简化多Option组合 #

如果觉得嵌套flatMap麻烦，可以用Vavr Option的zip方法组合getA()和getB()的结果：

public Option<CalcResult> otherMethod(Obj o) {
    return Option.when(o.getAttr(), () -> o)
                 .flatMap(obj -> Option.of(obj.getA())
                                       .zip(Option.of(obj.getB()))
                                       .flatMap(tuple -> calculate(tuple._1, tuple._2)));
}

• zip方法会把两个Option组合成Option<Tuple2<Integer, Integer>>，只有当两个Option都有值时才会存在结果。
• 后续用flatMap从Tuple中取出两个值，调用calculate。

总结 #

• 你第一种实现的双层flatMap确实可读性差，嵌套结构过多；
• 第二种实现的问题在于错误使用了Option.when的Supplier参数，导致前置条件处理不符合预期；
• 推荐的三种方案都遵循了Vavr的函数式风格，逻辑清晰且易于维护，你可以根据自己的代码风格偏好选择。

内容的提问来源于stack exchange，提问作者Pablo Alcantar