Почему классы Guava предоставляют столько методов factory, а не только один, который принимает varargs?

Возможный дубликат:
Почему у ImmavableList Guava так много перегруженных методов()?

Глядя на Guava ImmutableList (и некоторые другие классы), вы найдете множество перегруженных методов удобства of ( "Возвращает неизменяемый список, содержащий заданные элементы, в порядке." ), Которые принимают различное количество параметров:

...
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) 
...

Весь путь к этому:

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)

Некоторые мои коллеги считают это глупым, задаваясь вопросом, почему существует не только один метод: of(E... elements). Они подозревают, что "оптимизация" с ненадежным руководством относится к категории "как вы думаете, вы умнее компилятора" или что-то в этом роде.

Моя догадка заключается в том, что Кевин Бурриллион и др. поместите эти методы там по реальной причине. Может ли кто-нибудь объяснить (или предположить), что это за причина?

Ответы

Ответ 1

Комментарий в source говорит:

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

Итак, это было сделано, потому что методы varargs вызывают предупреждение с помощью общих аргументов.

Ответ 2

Я думаю, что избегать предупреждения unchecked generic array creation, когда E является общим типом.

Ответ 3

Чтобы избежать накладных расходов на создание массива varargs для наиболее распространенных случаев использования. Это моделируется после того, как был разработан EnumSet.of(..).

Ответ 4

Actaully компилятор действительно тупой, JVM имеет большую часть умений, но его все еще недостаточно умны, чтобы исключить необходимость создания массива для vararg.

Сохранение массива действительно того стоит, возможно, это то, о чем автор не хотел, чтобы пользователи беспокоились. то есть он может знать, что это не имеет большого значения, но не все пользователи могут понять, что не стоит беспокоиться об этом в 99% случаев.

Когда это были сборники google, это было частью описания "Высокопроизводительные неизменные реализации стандартных типов коллекций, например ImmutableSet"

Ответ 5

Я могу думать о том, чтобы избежать путаницы компилятором.

Если бы мы имели,

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

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

и в вашем коде у нас был

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

Компилятор не знает, нужно ли вызывать вариант 1 или вариант 2.

Должна быть веская причина, по которой Джош Блох, Кевин Бурриллион и его команда думали о "смешном" методе of(...).