根据 FXCop,List 不应该在 API 对象模型中公开。为什么这被认为是不好的做法?
6 回答
我同意这里的 moose-in-the-jungle:List<T>
是一个不受约束的、臃肿的物体,里面有很多“行李”。
IList<T>
幸运的是,解决方案很简单:改为暴露。
它公开了一个准系统接口,该接口具有大多数List<T>
's 方法(除了类似的方法AddRange()
),并且不会将您限制为特定List<T>
类型,这允许您的 API 使用者使用他们自己的自定义实现IList<T>
.
为了获得更大的灵活性,请考虑IEnumerable<T>
在适当的时候将一些集合公开给 。
有两个主要原因:
- List<T> 是一种相当臃肿的类型,其中许多成员在许多场景中都不相关(对于公共对象模型来说太“忙”了)。
- 该类是未密封的,但不是专门为扩展而设计的(您不能覆盖任何成员)
如果您正在编写一个将被成千上万的开发人员使用的 API,那么它只会被认为是不好的做法。
.NET 框架设计指南适用于 Microsoft 的公共 API。
如果你有一个没有被很多人使用的 API,你应该忽略这个警告。
我认为您不希望您的消费者在您的退货中添加新元素。API 应该清晰完整,如果它返回一个数组,它应该返回确切的数据结构。我认为这与 T per say 无关,而是直接返回 List<> 而不是数组 []
一个原因是因为 List 不是您可以模拟的东西。即使在不太受欢迎的库中,由于此建议,我也看到用于将 List 对象公开为 IList 的迭代,并且在以后的版本中决定根本不将数据存储在列表中(可能在数据库中)。因为它是一个 IList,所以更改客户端下的实现并保持每个人的工作并不是一个重大更改。
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.