java - 实现应该表现为 optional 类

想象一下，找出两个形状是否相交。两个形状的交集可以是其他形状，也可以不是。如果intersects(Shape)中没有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接口(interface)，如下所示:

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

如果我坚持在需要 optional 行为的情况下实现Maybe的解决方案，可能会有什么警告？另外，此任务似乎很普遍。我在这里通过引入自己的Maybe接口(interface)重塑车轮吗？

我还应该补充说，使用单独的类和接口(interface)的整个麻烦之处是可以忽略使用静态方法来实现行为。

最佳答案

正如rolfl所说，这是一个奇怪的想法。假设您要为两个int计算xy。有时它是未定义的，所以您会实现Maybe<Integer>吗？然后是另一个实现nCr(x，y)？

这听起来不对，不是吗？问题在于您将事物的起源(交叉，力量，选择)绑定(bind)到事物本身。但是两个Shape的交集又不过是Shape(或根本没有，可以通过Optional很好地表示。或者甚至可以更好地使用null；只不过叫我老派)。

面向对象的方法在这里毫无意义，因为没有新的对象。 22与nCr(4，1)完全相同，并且两者与4完全相同。

另一件事是，您必须调用ShapesIntersection构造函数。这实际上是一个静态调用，因此您也可以编写一个静态辅助方法。

用一些Shape扩展IntersectableShape可能是有道理的。在某些情况下，某些操作通常足以应付此类情况，请参见例如FluentIterable，但我怀疑您会进行那么多交叉。

关于java - 实现应该表现为 optional 类，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/29734073/