C# 为什么公开 List<T> 被认为是不好的？

Why is it considered bad to expose List<T>?

提问by David Robbins

According to FXCop, List should not be exposed in an API object model. Why is this considered bad practice?

根据 FXCop，List 不应在 API 对象模型中公开。为什么这被认为是不好的做法？

采纳答案by Jon Limjap

I agree with moose-in-the-jungle here: List<T>is an unconstrained, bloated object that has a lot of "baggage" in it.

我同意丛林中的驼鹿：它List<T>是一种不受约束、臃肿的物体，里面有很多“行李”。

Fortunately the solution is simple: expose IList<T>instead.

幸运的是，解决方案很简单：IList<T>改为公开。

It exposes a barebones interface that has most all of List<T>'s methods (with the exception of things like AddRange()) and it doesn't constrain you to the specific List<T>type, which allows your API consumers to use their own custom implementers of IList<T>.

它公开了一个准系统接口，该接口具有 的大部分List<T>方法（除了像 那样的东西AddRange()）并且它不会将您限制为特定List<T>类型，这允许您的 API 使用者使用他们自己的IList<T>.

For even more flexibility, consider exposing some collections to IEnumerable<T>, when appropriate.

为了获得更大的灵活性，请考虑IEnumerable<T>在适当的时候将一些集合暴露给。

回答by leora

i think you dont want your consumers adding new elements into your return. An API should be clear and complete and if it returns an array, it should return the exact data structure. I dont think it has anything to do with T per say but rather returning a List<> instead of an array [] directly

我认为您不希望您的消费者在您的退货中添加新元素。API 应该清晰完整，如果它返回一个数组，它应该返回准确的数据结构。我不认为它与 T per say 有任何关系，而是直接返回 List<> 而不是数组 []

回答by e11s

There are the 2 main reasons:

主要有2个原因：

• List<T> is a rather bloated type with many members not relevant in many scenarios (is too “busy” for public object models).
• The class is unsealed, but not specifically designed to be extended (you cannot override any members)

• List<T> 是一个相当臃肿的类型，其中许多成员在许多场景中都不相关（对于公共对象模型来说太“忙”了）。
• 该类是未密封的，但不是专门设计用于扩展的（您不能覆盖任何成员）

回答by Scott Wisniewski

It's only considered bad practice if you are writing an API that will be used by thousands or millions of developers.

如果您正在编写一个将被数千或数百万开发人员使用的 API，它只会被认为是不好的做法。

The .NET framework design guidelines are meant for Microsoft's public APIs.

.NET 框架设计指南适用于 Microsoft 的公共 API。

If you have an API that's not being used by a lot of people, you should ignore the warning.

如果您的 API 未被很多人使用，则应忽略该警告。

回答by Andrew Arnott

One reason is because List isn't something you can simulate. Even in less-popular libraries, I've seen iterations that used to expose a List object as an IList due to this recommendation, and in later versions decided to not store the data in a list at all (perhaps in a database). Because it was an IList, it wasn't a breaking change to change the implementation underneath the clients and yet keep everyone working.

一个原因是因为 List 不是您可以模拟的东西。即使在不太受欢迎的库中，我也看到过由于此建议而用于将 List 对象公开为 IList 的迭代，并且在以后的版本中决定根本不将数据存储在列表中（可能在数据库中）。因为它是一个 IList，所以改变客户端下的实现并让每个人都保持工作并不是一个破坏性的变化。

回答by Anton Kolesov

One of the reason is that user will be able to change the list and owner of the list will not know about this, while in some cases it must do some stuff after adding/removing items to/from the list. Even if it isn't required now it can become a requirement in future. So it is better to add AddXXX / RemoveXXX method to the owner of the class and expose list an an IEnumerable or (which is better in my opinion) expose it as an IList and use ObservableCollection from WindowsBase.

原因之一是用户将能够更改列表，而列表的所有者不会知道这一点，而在某些情况下，它必须在向/从列表中添加/删除项目后做一些事情。即使现在不需要，将来也可能成为要求。因此，最好将 AddXXX / RemoveXXX 方法添加到类的所有者并公开一个 IEnumerable 列表，或者（在我看来更好）将其公开为 IList 并使用 WindowsBase 中的 ObservableCollection。