为什么Java Collections Framework提供了两种不同的排序方式？
如果我有一个我想要排序的元素列表，Java提供了两种方法来解决这个问题。
例如，假设我有一个Movie对象列表，我想按标题对它们进行排序。
我可以这样做的一种方法是调用静态java.util.Collections.sort（）方法的单参数版本，并将我的电影列表作为单个参数。 所以我会调用Collections.sort（myMovieList）。 为了使其工作，必须声明Movie类以实现java.lang.Comparable接口，并且必须在此类中实现所需的方法compareTo（）。
另一种排序方法是使用影片列表和java.util.Comparator对象作为参数调用静态java.util.Collections.sort（）方法的双参数版本。 我会调用Collections.sort（myMovieList，titleComparator）。 在这种情况下，Movie类不会实现Comparable接口。 相反，在构建和维护影片列表本身的主类中，我将创建一个实现java.util.Comparator接口的内部类，并实现一个必需的方法compare（）。 然后我将创建此类的实例并调用sort（）的双参数版本。 第二种方法的好处是您可以创建无限数量的这些内部类比较器，因此您可以以不同的方式对对象列表进行排序。 在上面的示例中，您可以让另一个Comparator按照制作电影的年份进行排序。
我的问题是，为什么麻烦学习两种方式在Java中进行排序，当Collections.sort（）的双参数版本执行第一个单参数版本所做的所有事情时，还有一个额外的好处就是能够对列表的元素进行排序根据几个不同的标准？ 在编码时必须记住这一点。 你有一个基本的机制来排序Java中的列表来了解。
一个是简洁应该是一个常见的案例（ Effective Java 2nd Edition，Item 12：考虑实现Comparable ）。 正如您所指出的，另一个是灵活性和通用性。
相关问题
- compare（）和compareTo（）之间的区别
- 何时使用Comparable vs Comparator
- 关于null的可比较和比较者合同
- 我可以使用比较器而不实现Comparable吗？
这取决于谁控制订购。 如果对象的排序是对象的实现细节，则Comparable更合适。 如果对象的排序由调用者控制，则Comparator更合适。
我不确定我觉得这很奇怪。 我有一个要排序的东西列表，它们有一个像数字这样的自然顺序。 我真的希望我必须告诉API如何比较数字吗？ 我不会直观地寻找一个双精度方法。 因此可比较存在。
但是，当然你可以而且应该能够定义不同的顺序，因此另一种方法。 例如，即使数字具有自然顺序，我仍然可能需要不同的顺序：例如，按值降序排序。 因此比较者存在。
当然，有些东西没有像Fruit这样的自然顺序，但您可能仍希望订购它们的列表。 比如，比较者。