应该将可比与其他类型进行比较吗？

Question

我想知道是否存在以下有效用例：

class Base {}

class A implements Comparable<Base> {
    //...
}

接受类型为where
的集合似乎是一种常见的模式（请参见Collections中的许多示例）。T``T extends Comparable<? super T>

但是，compareTo()与基类进行比较时，在技术上似乎无法履行合同，因为无法确保另一类不会通过矛盾的比较来扩展基数。考虑以下示例：

class Base {
    final int foo;
    Base(int foo) {
        this.foo = foo;
    }
}

class A extends Base implements Comparable<Base> {
    A(int foo) {
        super(foo);
    }
    public int compareTo(Base that) {
        return Integer.compare(this.foo, that.foo); // sort by foo ascending
    }
}

class B extends Base implements Comparable<Base> {
    B(int foo) {
        super(foo);
    }
    public int compareTo(Base that) {
        return -Integer.compare(this.foo, that.foo); // sort by foo descending
    }
}

我们有两个类，它们Base使用不遵循共同规则的比较进行扩展（如果存在共同规则，则几乎可以肯定在中实现Base）。但是，下面的破碎类将被编译：

Collections.sort(Arrays.asList(new A(0), new B(1)));

只接受不安全T extends Comparable<T>吗？还是有一些用例可以验证通配符？

Answer 1

这个问题问得好。首先，让我们从Collections使用诸如

binarySearch(List<? extends Comparable<? super T>> list, T key)

确实，为什么不只是

binarySearch(List<? extends Comparable<T>> list, T key)

这样做的原因是PECS原则：生产者扩展，消费者超级。怎么binarySearch办？它从列表中 读取 元素，然后通过 将 其值 传递
给compareTo函数进行比较。由于列表读取元素，因此它充当了生产者，因此，第一部分即生产者扩展。这很明显，那么“超级消费者”部分又如何呢？

Consumer
Super本质上意味着，如果仅要将值传递给某个函数，则不必在乎它是否接受对象的确切类型还是对象的某些超类。因此，binarySearch声明的意思是：只要可以将任何内容传递给compareTolist元素的方法，我都可以查找任何内容。

在排序的情况下，并不是很明显，因为仅将元素相互比较。但是即使那样，如果Base实际上实现了Comparable<Base>（整个比较是否完成）A并且B仅仅扩展Base而又不以任何方式进行比较又会怎样呢？然后，您将无法对A和的列表进行排序，B因为它们分别未实现Comparable<A>和Comparable<B>。每次子类化时，您都必须重新实现整个接口！

另一个例子：如果有人想对包含某个类实例甚至不扩展您的实例的列表进行二进制搜索，该怎么办Base？

class BaseComparable implements Comparable<Base> {
    private final Base key;
    // other fields

    BaseComparable(Base key, ...) {
        this.key = key;
        // other fields initialization
    }

    @Override
    public int compareTo(Base otherKey) {
        return this.key.compareTo(otherKey);
    }
};

现在，他们希望使用的实例A作为此二进制搜索的关键字。由于? super T部分原因，他们只能这样做。请注意，此类不知道键是a
A还是a，B因此无法实现Comparable<A/B>。

至于您的示例，我想这只是一个糟糕的设计示例。不幸的是，我认为在不破坏PECS原理和/或限制Java泛型已经有限的功能的情况下，无法防止此类情况。