为什么Guava类提供了如此多的工厂方法而不是只提供varargs的方法？

可能重复：
为什么Guava的ImmutableList有这么多重载的（）方法？

看看Guava的ImmutableList （以及其他一些类），你会发现大量的方便方法（“返回包含给定元素的不可变列表，按顺序。”），它们采用不同数量的参数：

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

一直到这个：

 public static  ImmutableList 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) 。 他们怀疑这是一个不良导向的性能“优化”，属于“你认为你比编译器更聪明”的类别，或类似的东西。

我的预感是Kevin Bourrillion等人。 把这些方法放在那里是出于真正的原因。 谁能解释（或推测）这个理由可能是什么？

Answer 1

消息来源中的评论说：

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

所以，这是因为varargs方法产生带有generics参数的警告。

Answer 2

我认为当E是generics类型时，应避免unchecked generic array creation警告。

Answer 3

这是为了避免为最常见的用例创建varargs数组的开销。 这是在EnumSet.of（..）的设计方式之后建模的。

Answer 4

实际上编译器非常愚蠢，JVM具有大部分智能，但它仍然不够智能，无法为vararg创建arrays。

是否真的值得保存arrays，也许是作者不希望用户担心的事情。 也就是说，他可能知道它并没有太大的区别，但并非所有用户都会意识到99％的时间都不值得担心。

当它是google-collections时，这是描述“标准集合类型的高性能不可变实现，例如ImmutableSet”的一部分

Answer 5

我能想到的是避免编译器混淆。

如果我们只有，

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

和

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

在你的代码中我们有

 ImmutableList list = ImmutableList.of("Value"); 

编译器不知道是调用选项1还是选项2。

Josh Bloch，Kevin Bourrillion和他的团队必须有一个合理的理由，认为他们of(...)方法有“荒谬” of(...)看法。