我知道将所有List实现都转换为会被普遍接受List。无论它是一个变量，方法返回，或参数使用的方法ArrayList，CopyOnWriteArrayList等。
List<Market> mkts = new ArrayList<>();
当我使用Guava时ImmutableList，我认为它可以说是该规则的例外（尤其是如果我在内部构建复杂的业务应用程序而不是公共API）。因为如果我将其强制转换为列表，那么不推荐使用的mutator方法将不再标记为不推荐使用。而且，它不再被标识为不可变的对象，这是其功能和身份的重要组成部分。
List<Market> mkts = ImmutableList.of(mkt1,mkt2,mkt3);
因此，将其作为ImmutableList权利传递是有意义的吗？我什至可以争辩说，内部API只接受的好策略ImmutableList，因此客户端的可变性和多线程不会破坏库中的任何内容。
ImmutableList<Market> mkts = ImmutableList.of(mkt1,mkt2,mkt3);
我知道自己有被ImmutableList过时的风险，而Oracle决定创建自己的一天ImmutableList将需要大量重构。但是，是否有理由认为维持ImmutableList演员阵容的利弊大于弊？
我同意你的理由。如果您正在使用Guava集合库，并且您的列表是不可变的，则最好将它们传递给您ImmutableList。
然而：
我知道ImmutableList本身有被弃用的风险，而Oracle决定创建自己的ImmutableList的那一天将需要大量的重构。
第一种情况似乎不太可能，但是每当您使用任何第三方库时，您都将承担风险。但是，不利的一面是，如果应用程序（谷歌）无意中弃用了您依赖的类或方法，则可以选择不升级应用程序的Guava版本。
更新
Louis Wasserman（为Google工作）在评论中说：
“ Guava为非@Beta API提供了非常强大的兼容性保证。”
因此，我们可以减少不必要的API更改的可能性。
第二种情况更不可能发生（IMO）。而且您可以确定，如果Oracle确实添加了不可变的列表类或接口，则不需要您进行重构。Oracle会尽力避免在增强标准API时破坏现有代码。
但是话虽如此，您实际上要权衡利弊...以及最终结果时如何应对。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句