Warum liefern Guava-Klassen so viele Fabrik-Methoden, anstatt nur eine, die Varargs braucht?

Question

Mögliche Duplizieren:
Why does Guava's ImmutableList have so many overloaded of() methods?

bei Guava sucht ImmutableList (und einigen anderen Klassen), werden Sie viele überladene of Bequemlichkeit Methoden ("Gibt eine unveränderliche Liste mit den finden gegeben Elemente, in der Reihenfolge. "), die eine andere Anzahl von Parametern annehmen:

... 
public static <E> ImmutableList<E> of(E e1, E e2, E e3) 
public static <E> ImmutableList<E> of(E e1, E e2, E e3, E e4) 
public static <E> ImmutableList<E> of(E e1, E e2, E e3, E e4, E e5) 
... 

Den ganzen Weg zu dieser:

public static <E> ImmutableList<E> of(E e1, 
             E e2, 
             E e3, 
             E e4, 
             E e5, 
             E e6, 
             E e7, 
             E e8, 
             E e9, 
             E e10, 
             E e11, 
             E e12, 
             E... others) 

Einige Kollegen von mir diesen dummen betrachten, fragen, warum es ist nicht nur eine Methode: of(E... elements). Sie vermuten, dass es eine schlecht geführte Performance- "Optimierung" ist, die in die Kategorie "Denkst du, du bist schlauer als Compiler" oder so ähnlich fällt.

Meine Ahnung ist, dass Kevin Bourrillion et al. Setze diese Methoden aus einem echten Grund ein. Kann jemand erklären (oder spekulieren), was dieser Grund sein könnte?

Answer 1

Der Kommentar in der source sagt:

// These go up to eleven. After that, you just get the varargs form, and 
// whatever warnings might come along with it. :(

Also, das da getan wurde varargs Methoden eine Warnung mit generischen Argumenten erzeugen.

Answer 2

Es ist der Aufwand für die Erstellung eines Varargs-Array für die häufigsten Anwendungsfälle zu vermeiden. Dies ist nach dem Vorbild EnumSet.of(..) gestaltet.

Answer 3

Ich denke, es ist zu vermeiden unchecked generic array creation Warnung, wenn E ein generischer Typ ist.

Answer 4

Wirklich der Compiler ist wirklich dumm, die JVM hat die meisten Smart, aber es ist immer noch nicht schlau genug, um die Notwendigkeit zu beseitigen, ein Array für einen Vararg zu erstellen.

Ob sich das Speichern des Arrays wirklich lohnt, ist vielleicht etwas, worüber der Autor sich keine Sorgen machen sollte. vielleicht weiß er, dass es keinen großen Unterschied macht, aber nicht alle Benutzer wissen, dass es sich in 99% der Fälle nicht lohnt, sich darüber Gedanken zu machen.

Wenn es Google-Sammlungen waren, war dieser Teil der Beschreibung „High-Performance unveränderlicher Implementierungen der Standardsammlungstypen, zum Beispiel ImmutableSet“

Answer 5

Was kann ich mich vorstellen ist Verwirrung durch den Compiler zu vermeiden.

Wenn wir nur hatten,

public static ImmutableList<E> of(E element); //Option 1 

und

public static ImmutableList<E> of(E... elements); //Option 2 

und in Ihrem Code hatten wir

ImmutableList<String> list = ImmutableList.of("Value"); 

Der Compiler würde nicht wissen, ob 1-Option aufzurufen oder Option 2.

Die Das muss ein berechtigter Grund sein, warum Josh Bloch, Kevin Bourrillion und sein Team "lächerlich" auf die Methode of(...) dachten.