java - 为什么从创建列表的方法返回 unmodifyingList 更好？

Question

 public List<Integer> getInts()
{
    List<Integer> xs = new ArrayList<Integer>();
    xs.add(1);
    // return Collections.unmodifiableList(xs);
    return xs;
}   

我知道返回不可修改的列表将阻止消费者向列表引用添加其他元素，但除此之外，通过将其包装在不可修改的列表中我还能获得什么？每次调用该方法时我都会创建一个新列表。

Answer 1

Bohemian 的答案阐述了一些关于返回不可修改、不可变或防御性复制数据的良好通用原则，以保持封装性。如果数据位于对象内部(例如存储在字段中)，则这当然是正确的。

但是，OP 指出每次调用该方法时都会重新创建返回的列表。在这种情况下，为什么返回一个不可修改的列表而不是常规的 ArrayList？这是有原因的，但它们有些微妙，而且它们与封装的关系不大，而与保留实现灵 active 有关。

作为背景主题，您需要确定此 API 是否有任何长期兼容性限制或策略。如果您返回一个可变列表，那么调用者可能(根据 Hyrum's Law )将依赖于它的可变性。 (海勒姆定律本质上规定，系统的任何可观察属性最终都将受到用户的依赖。)我个人认为，改变返回给您的集合是草率的编程，但事实是，人们确实这样做了。如果是这种情况，并且将来您建议将返回的列表更改为不可修改，是否会因为它不兼容并且会破坏某些调用者而被禁止？如果您不关心兼容性(有些项目不关心)，那么也许这并不重要。但如果您这样做，那么您应该考虑立即返回一个不可修改的列表。

一个原因(其他人在评论中提到)是您可能决定不每次都创建一个新列表，但您可能会缓存它并将其返回给多个调用者。如果您这样做，则绝对应该将其设置为不可修改，以防止一个调用者修改列表并影响所有列表。

另一个原因是不同的列表实现具有不同的性能和空间特性。 Collections.singletonList 和 List.of(x) 实现将其单个元素存储在 List 对象本身的字段中，而 ArrayList 存储其单个元素元素——即使只有一个——在一个单独的数组对象中。小列表实现可以节省大量空间 与 ArrayList 相比，如果您要创建很多数组。如果您将来想切换到单例列表或 Java 9 不可修改列表实现，则返回 ArrayList 周围的不可修改包装器将缓解兼容性问题。

您可能还想向该方法添加一些自适应行为，例如，根据返回列表中的元素数量。例如，

if (count == 0) {
    return Collections.emptyList(); // eventually, List.of()
} else if (count == 1) {
    return Collections.singletonList(i); // eventually, List.of(i)
} else {
    List<Integer> list = new ArrayList<>();
    // populate list
    return Collections.unmodifiableList(list);
}

如果您不将 ArrayList 包装在不可修改的包装器中，调用者将面临奇怪的行为差异，例如列表有时可修改，有时不可修改。如果可能，最好在所有情况下提供统一的行为，从而为 future 的更改保留实现灵 active 。