明智地使用重载(Use overloading judiciously)

 
 
 除了标准的TreeSet之外，TreeSet的构造函数还包括一个允许您提供Comparator的构造函数，以及一个允许您从另一个SortedSet创建一个的构造函数： 
 
 
TreeSet(Comparator<? super E> c)
// construct an empty set which will be sorted using the
// specified comparator 
TreeSet(SortedSet<E> s)
// construct a new set containing the elements of the 
// supplied set, sorted according to the same ordering
 
 
 其中第二个与标准“转换构造函数”的声明相当接近： 
 
 
TreeSet(Collection<? extends E> c)
 
 
 正如Joshua Bloch在Effective Java中解释的那样（在“方法”一章中“明智地使用重载”项），调用两个带有相关类型参数的构造函数或方法重载之一会产生令人困惑的结果。 这是因为，在Java中，基于参数的静态类型在编译时解析对重载的构造函数和方法的调用，因此对参数应用强制转换可以对调用的结果产生很大的影响，因为以下代码显示： 
 
 
// construct and populate a NavigableSet whose iterator returns its
// elements in the reverse of natural order:
NavigableSet<String> base = new TreeSet<String>(Collections.reverseOrder());
Collections.addAll(base, "b", "a", "c");

// call the two different constructors for TreeSet, supplying the
// set just constructed, but with different static types: 
NavigableSet<String> sortedSet1 = new TreeSet<String>((Set<String>)base);
NavigableSet<String> sortedSet2 = new TreeSet<String>(base);
// and the two sets have different iteration orders: 
List<String> forward = new ArrayList<String>(); 
forward.addAll(sortedSet1);
List<String> backward = new ArrayList<String>(); 
backward.addAll(sortedSet2);
assert !forward.equals(backward); 
Collections.reverse(forward); 
assert forward.equals(backward);
 
 
 此问题折磨了Framework中所有已排序集合的构造函数（TreeSet，TreeMap，ConcurrentSkipListSet和ConcurrentSkipListMap）。 要在您自己的类设计中避免它，请为不同的重载选择参数类型，以便不能将适合于一个重载的类型的参数强制转换为适合不同类型的类型。 如果这是不可能的，那么两个重载应设计成与相同的参数相同，无论其静态类型如何。 例如，从集合构造的PriorityQueue使用原始的排序，无论提供构造函数的静态类型是包含Comparator的类型PriorityQueue还是SortedSet之一，或者只是普通的Collection。 为实现此目的，转换构造函数使用所提供集合的Comparator，如果没有，则只返回自然顺序。 
 
 
 目前，我正在阅读一本名为Java Generics and Collections的书，以上是我不理解的内容[page185~186]。 
 
 首先，我不太明白为什么它使用这个例子以及它想要说明的内容。 
 
 其次，我不太了解“转换构造函数”的概念。 是因为转换构造函数的存在，我们应该明智地使用重载吗？ 

 
 
The constructors for TreeSet include, besides the standard ones, one which allows you to supply a Comparator and one which allows you to create one from another SortedSet:
 
 
TreeSet(Comparator<? super E> c)
// construct an empty set which will be sorted using the
// specified comparator 
TreeSet(SortedSet<E> s)
// construct a new set containing the elements of the 
// supplied set, sorted according to the same ordering
 
 
The second of these is rather too close in its declaration to the standard "conversion constructor” :
 
 
TreeSet(Collection<? extends E> c)
 
 
As Joshua Bloch explains in Effective Java (item “Use overloading judiciously” in the chapter on Methods), calling one of two constructor or method overloads which take parameters of related type can give confusing results. This is because, in Java, calls to overloaded constructors and methods are resolved at compile time on the basis of the static type of the argument, so applying a cast to an argument can make a big difference to the result of the call, as the following code shows:
 
 
// construct and populate a NavigableSet whose iterator returns its
// elements in the reverse of natural order:
NavigableSet<String> base = new TreeSet<String>(Collections.reverseOrder());
Collections.addAll(base, "b", "a", "c");

// call the two different constructors for TreeSet, supplying the
// set just constructed, but with different static types: 
NavigableSet<String> sortedSet1 = new TreeSet<String>((Set<String>)base);
NavigableSet<String> sortedSet2 = new TreeSet<String>(base);
// and the two sets have different iteration orders: 
List<String> forward = new ArrayList<String>(); 
forward.addAll(sortedSet1);
List<String> backward = new ArrayList<String>(); 
backward.addAll(sortedSet2);
assert !forward.equals(backward); 
Collections.reverse(forward); 
assert forward.equals(backward);
 
 
This problem afflicts the constructors for all the sorted collections in the Framework (TreeSet, TreeMap, ConcurrentSkipListSet, and ConcurrentSkipListMap). To avoid it in your own class designs, choose parameter types for different overloads so that an argument of a type appropriate to one overload cannot be cast to the type appropriate to a different one. If that is not possible, the two overloads should be designed to behave identically with the same argument, regardless of its static type. For example, a PriorityQueue constructed from a collection uses the ordering of the original, whether the static type with which the constructor is supplied is one of the Comparator-containing types PriorityQueue or SortedSet, or just a plain Collection. To achieve this, the conversion constructor uses the Comparator of the supplied collection, only falling back on natural ordering if it does not have one.
 
 
Currently, I am reading the book called Java Generics and Collections, and above is something I don't understand [page185~186].
 
First, I don't quite understand why it uses this example and what things it want to illustrate.
 
Second, I don't quite understand the concept of "conversion constructor". Is it because of the existence of conversion constructor, that we should use overloading judiciously? 

原文：https://stackoverflow.com/questions/31712397