1700444904
1700444905
//排序
1700444906
1700444907
Collections.sort（cities）；
1700444908
1700444909
//查找对象
1700444910
1700444911
City city=new City（“021”，“沪”）；
1700444912
1700444913
//indexOf方法取得索引值
1700444914
1700444915
int index1=cities.indexOf（city）；
1700444916
1700444917
//binarySearch查找到索引值
1700444918
1700444919
int index2=Collections.binarySearch（cities, city）；
1700444920
1700444921
System.out.println（“索引值（indexOf）：”+index1）；
1700444922
1700444923
System.out.println（“索引值（binarySearch）：”+index2）；
1700444924
1700444925
}
1700444926
1700444927
输出的index1和index2应该一致吧，都是从一个列表中查找相同的元素，只是使用的算法不同嘛。但是很遗憾，结果不一致：
1700444928
1700444929
索引值（indexOf）：0
1700444930
1700444931
索引值（binarySearch）：1
1700444932
1700444933
indexOf返回的是第一个元素，而binarySearch返回的是第二个元素（索引值是1），这是怎么回事呢？
1700444934
1700444935
这是因为indexOf是通过equals方法判断的，equals等于true就认为找到符合条件的元素了，而binarySearch查找的依据是compareTo方法的返回值，返回0即认为找到符合条件的元素。
1700444936
1700444937
仔细审查一下代码，我们覆写了compareTo和equals方法，但是两者并不一致。使用indexOf方法查找时，遍历每个元素，然后比较equals方法的返回值，因为equals方法是根据code判断的，因此当第一次循环时，equals就返回了true, indexOf方法结束，查找到指定值。而使用binarySearch二分法查找时，依据的是每个元素的compareTo方法返回值，而compareTo方法又是依赖name属性的，name相等就返回0，binarySearch就认为找到元素了。
1700444938
1700444939
问题明白了，修改也就很容易了，将equals方法修改成判断name是否相等即可，虽然可以解决问题，但这是一个很无奈的解决办法，而且还要依赖我们的系统是否支持此类修改，因为相等逻辑已经发生了很大的变化。
1700444940
1700444941
从这个例子中，我们可以理解两点：
1700444942
1700444943
indexOf依赖equals方法查找，binarySearch则依赖compareTo方法查找。
1700444944
1700444945
equals是判断元素是否相等，compareTo是判断元素在排序中的位置是否相同。
1700444946
1700444947
既然一个是决定排序位置，一个是决定相等，那我们就应该保证当排序位置相同时，其equals也相同，否则就会产生逻辑混乱。
1700444948
1700444949
注意 实现了compareTo方法，就应该覆写equals方法，确保两者同步。
1700444950
1700444951
1700444952
1700444953
[
上一页 ]
[ :1.700444904e+09 ]
[
下一页 ]