Java 是否使用compareTo

我必须比较自定义类的对象，比如a

比较是基于一个int成员（比如mem）的简单比较

因此，在comparator实现中，我可以：

(A a1, A a2) -> {return (Integer)a1.getMem().compareTo(a2.getMem());}

或者，我可以自己做比较：

(A a1, A a2) -> {
     if(a1.getMem() > a2.getMem()){
         return 1;
     }else{
        if(a1.getMem() < a2.getMem()) {
            return -1;
         }else{
             return 0
          }
     }
}

（a1，a2）->{
if（a1.getMem（）>a2.getMem（））{
返回1；
}否则{
if（a1.getMem（）

哪种方法更好

---

第一种方法的代码行数要少得多，但与第二种方法相比，内部代码行数相同。

通常最好不要重新发明轮子。因此，第一种方法更好

您甚至可以使用以下工具编写更少的代码：

---

走第一条路。它比一堆if语句和返回的幻数更具可读性（如何比较两个

A

s？

compare

它们的

getMem

）。此外，使用库中的方法（如

compareTo

）比自己编写一堆比较逻辑更不容易出错。想象一下，将

-1

误输入为

1

或将

误输入为代码>

但是，还有一种更好的方法：

Comparator.comparingInt(A::getMem)

---

获得“良好”代码库的最基本规则之一是：避免代码重复，就像瘟疫一样

这不仅仅是写最少的代码来解决问题。它实际上是关于：在多个地方没有相同的逻辑

为什么?？因为，当您决定在某个时刻更改该逻辑时，您必须记住更新包含该逻辑的所有位置

有研究表明，大型项目中的代码复制迟早会导致某个逻辑片段有多个几乎相同的克隆。猜猜看：那就是虫子藏身的地方。从10行中复制9行，然后在这9行中进行细微的修改。或者你只是添加了一个bug，或者你在这9行中修复了一个问题，但在原来的10行中没有。现在代码中的两个地方做的事情略有不同。很少是好事

因此，请遵循另外两个答案，但请理解为什么要这样做

---

不要搞错了：在某个时候，您可能会认为这种与实现的比较不再是您所需要的。那么，把它换成别的东西，并把它完整地写在这里，这是完全可以的。但直到那一天：重新使用已经存在的代码

我不会使用这两种方法，而是

Integer.compare（a1.getMem（），a2.getMem（））

来避免强制转换。但通常使用第二种方法，并且（几乎）总是尝试使用现有的API来完成您的工作，而不要重新发明轮子。这避免了您这边的错误，因为您不能像在方法2中那样将问题添加到比较算法中。

Comparator.comparingInt(A::getMem)