java - 实现应表现为 Optional 的类

Question

想象一下，找出两个形状是否相交。两个形状的交集可能是另一种形状，也可能什么都不是。如果 Shape 中没有 intersects(Shape) 方法，那么我相信正确的面向对象解决方案是:

public final class ShapesIntersection implements Maybe<Shape> {
    public ShapesIntersection(Shape a, Shape b) {
        this.a = a;
        this.b = b;
    }

    @Override
    public boolean isPresent() {
        // find out if shapes intersect
    }

    @Override
    public Shape get() {
        // find the common piece of two shapes
    }
}

在 JDK 中，Optional 是一个 final 类，而不是一个接口(interface)。为了正确解决此类问题，我将编写自己的 Maybe 界面，如下所示:

public inteface Maybe<T> {
    T get();
    boolean isPresent();
    default Optional<T> asOptional() {
       return isPresent() ?
           Optional.of(get()) :
           Optional.empty();
    }
}

如果我坚持在需要可选行为时实现 Maybe 的解决方案，可能会有什么注意事项？而且，这个任务似乎很普遍。引入我自己的 Maybe 界面是不是在重新发明轮子？

我应该补充一点，使用单独的类和接口(interface)的整个麻烦在于忽略使用静态方法实现行为。

Answer 1

您正在重新发明轮子。 Optional 是 final 的原因是因为实际上没有理由更改它，并且内部语义需要在整个用法中保持一致。

这里真正的问题是构造函数的逻辑。您不应该使用构造函数来确定交集的逻辑。你想要的是一个(静态的？)方法来为你执行计算，并返回相关的 Optional。

public static Optional<Shape> intersection(Shape a, Shape b) {
    // compute if there is an overlap
    if (!checkOverlaps(a,b)) {
        return Optional.empty();
    }
    Shape intersection  = ....
    return Optional.of(intersection);
}

请注意 Optional.empty()和 Optional.of(....)是创建 Optional 的适当实例的工厂方法。 Java 8 流、函数和其他支持结构使用大量静态工厂方法来创建这些最终类的实例。