为什么要在内部使用 MyObject[]，但公开 List？

Question

我遇到过一个具有不可变属性的类：

MyObject[] allObjs

该属性的初始化如下：

List<MyObject> objs = createAllMyObjects();
allObjs = objs.toArray(new MyObject[objs.size()]);

当它通过访问器公开时，它以列表形式完成：

public List<MyObject> getAllMyObjects() {
    return Collections.unmodifiableList(Arrays.asList(allObjs));
}

程序员为什么要这样做？难道还有什么我不知道的好处吗？

性能不是问题，因为 obj 数组只会包含几十个元素。

看来我们一直在兜圈子。

该类是一种工厂，因此它有一个私有构造函数，并且仅公开静态方法（不确定这是否是疯狂的原因）。

编辑

我想我的问题确实是，“为什么不只使用内部 ListallObjs 而不是 MyObject[] allObjs，并且返回 Collections.unmodifyingList(allObjs)？”因为这会完成同样的事情。

Answer 1

我看到的唯一原因是“在滥用的情况下尽早失败”（如果这个设计选择不是随机的并且有意义，那么这意味着他很少信任他的特定客户）。

MyObject[] 是具体化的，并且在运行时检查，而 List 则不是。人们可以在后者中隐藏非 MyObject 引用（当然，他会在编译时收到未经检查的警告），这将在未来某个未定义的点失败，并出现 ClassCastException ，但他不能对 < code>MyObject[] - 在误用时会立即失败。

但请注意，如果客户端是在泛化之前使用此 API 的预构建二进制文件，则没有人会收到未经检查的警告，因此如果此代码尝试迁移预泛型客户端使用的代码，则这是有意义的。

（实现相同结果的另一种方法是使用 List 并且还需要 Class，以便后者可以提供运行时类型检查。但是例如，需要另一个构造函数参数 - 现有客户端不会自动利用它 **更新：** 这基本上描述了 Sauer 在第一条评论中提到的 API 调用，因此不必重新发明它，只需使用即可。那个 ：） ）。

Answer 2

造成这种情况的原因可能有几个：

• 他们不知道自己在做什么。我现在正在编写的代码似乎是由刚接触 Java 和编程的人编写的。不幸的是，遇到设计糟糕的代码比找到由对平台有深入了解的人编写的良好、干净、维护良好的代码更常见。这部分是因为下一点。
• List 更改已修补，但不想进行大规模更改。如果代码的其余部分使用该数组，则有人可能不想费心进行所有其他更改。
• 虽然集合是更 OO/Java 的做事方式，但如果列表是静态的，则数组实际上“更容易”使用，因为它们仍然可以像集合一样使用 for(:) 进行迭代但使用 [] 而不是 get() 进行访问。就我个人而言，这并不是使用数组的充分理由，但也许这只是我的观点。
• 也许他们希望明确数据的长度是最终的。如果他们刚刚使用了不可修改的列表，List 仍然是引用数据的方法，任何不注意其余代码（希望有注释）的人可能会尝试添加到 < code>List 这将导致运行时 UnsupportedOperationException。使其成为数组使其用法更加清晰。

Answer 3

看来作者打算返回一个不可变的副本，但这样做是多余的。我假设选择 List 作为返回类型，以便可以使用 MyObject 类型轻松创建克隆。

Answer 4

有充分的理由不返回对内部 MyObject[] 属性的引用。调用者可以通过引用对数组进行更改。

如果没有理由结果必须是 List，您还可以返回数组的副本：

public MyObject[] getAllMyObjects() {
    MyObject[] result = new MyObject[allObjs.length];
    system.ArrayCopy(allObjs, 0, result, 0, result.length);
    return result;
}

Update，在添加问题后：
您是对的，如果将内部属性更改为列表，则将其包装为不可修改会更容易。

该类使用数组而不是列表的原因可能是性能。如果数组在对象的生命周期内变化不大并且迭代次数很多，则数组的开销比 List 少。

如果性能是使用数组的原因，您可以通过存储仅用于返回的 List 来防止在 getter 中创建额外的对象，即：

allObjsList = Collections.unmodifiableList(createAllMyObjects());
allObjs = allObjsList.toArray(new MyObject[allObjsList.size()]);

像以前一样使用 allObjs 数组并在 getter 中返回存储的列表：

public List<MyObject> getAllMyObjects() {
    return allObjsList ;
}

Answer 5

我用一个笑话来回答吧：

新的犹太新娘正在为她的丈夫做她的第一顿丰盛的晚餐，并尝试着她母亲的牛胸肉食谱，像她母亲一贯的方式切掉烤肉的末端。老公觉得肉很好吃，但又说：“你为什么要把两端切掉——那是最好的部分！”她回答道：“我妈妈总是这样做。

下周他们去了老巴比的家，她准备了著名的牛胸肉食谱，再次切掉了两端。年轻的新娘确信她一定错过了一些重要的信息，所以她问奶奶为什么要剪掉末端。奶奶说：“Dahlink，这是它能放进锅里的唯一方法！”

虽然我们当然可以找到一些论据来证明特定决定的合理性，但实际上这很少会产生任何影响，而且通常这样的决定背后没有任何意图。

使用最简单、最容易阅读的选项。可读性往往比聪明性更重要。

Answer 6

我没有看到使用数组而不是列表有任何优势。列表要舒服得多。也许这家伙只是喜欢使用数组:)

Answer 7

我认为这背后的原因可能是数组不可修改。但是，您可以将内部列表保留为 List，并仅在 getter 中返回它的副本，这样内部列表仍然无法从外部修改。

或者使用 Collections.unmodifyingList() 返回的“不可修改”列表...

在这种情况下，我也看不到任何性能优势，因为来回转换无论如何都需要一些周期。

Answer 8

这种方式集合是不可修改的，即调用者不能修改成员数组。
无法使用数组执行此操作，因此编码器将其复制到列表中。

Answer 9

在Java Generics一书中，作者实际上说既然我们有了泛型，我们就应该专门使用集合并且不应再使用数组。就我个人而言，我现在倾向于远离数组，因为集合可以帮助我记住使用集合的意图，例如。设置与列表相对于数组，它并没有真正告诉我有关数据的任何信息。

此外，除了快速复制（System.arraycopy（））之外，没有任何事情是我不能对集合做的，而不能对数组做的。