列表/数组/ReadOnlyCollection 创建（和使用）的最佳实践

Question

我的代码中充斥着集合——我想这并不是什么不寻常的事情。然而，各种集合类型的使用并不明显也不简单。一般来说，我想使用公开“最佳”API 且语法噪音最少的类型。 （请参阅返回值数组时的最佳实践 ，针对类似问题使用列表数组 - 最佳实践）。有一些指南建议在 API 中使用什么类型，但这些指南在普通（非 API）代码中是不切实际的。

例如：

new ReadOnlyCollection<Tuple<string,int>>(
    new List<Tuple<string,int>> {
        Tuple.Create("abc",3),
        Tuple.Create("def",37)
    }
)

列表是一种非常常见的数据结构，但是以这种方式创建它们会涉及相当多的语法噪音 - 而且很容易变得更糟（例如字典） ）。事实证明，许多列表从未改变，或者至少从未扩展。当然，ReadOnlyCollection 引入了更多语法噪音，它甚至没有完全传达我的意思；毕竟，ReadOnlyCollection 可能会包装一个变异集合。有时我在内部使用数组并返回 IEnumerable 来指示意图。但大多数这些方法的信噪比都非常低；这对于理解代码绝对至关重要。

对于 99% 的代码不是公共 API，没有必要遵循框架指南：但是，我仍然想要一个可理解的代码和一个能够传达意图的类型。

那么，处理制作小集合来传递值的标准任务的最佳实践方法是什么？ 在可能的情况下，数组应该优先于 List 吗？完全是别的东西吗？传递如此小的集合的最佳方式是什么——干净、可读、相当有效？特别是，代码对于未来的维护者来说应该是显而易见的，他们还没有阅读过这个问题，并且不想阅读大量的 API 文档，但仍然了解其意图是什么。 最大限度地减少代码混乱也非常重要 - 因此像 ReadOnlyCollection 这样的东西充其量是值得怀疑的。对于具有较小表面的主要 API 而言，冗长的类型没有什么问题，但作为大型代码库中的一般做法则不然。

在没有大量代码混乱（例如显式类型参数）但仍能清晰传达意图的情况下传递值列表的最佳方法是什么？

编辑：澄清这是为了制作简短、清晰的代码，而不是公共 API。

Answer 1

希望理解您的问题后，我认为您必须区分您在班级中创建和管理的内容以及您向外界提供的内容。

在您的班级中，您可以使用最适合您当前任务的任何内容（List 与 Array 与 Dictionary 与 的优缺点LinkedList 与等）。但这可能与您在公共属性或函数中提供的内容无关。

在你的公共合约（属性和函数）中，你应该返回所需的最少类型（甚至更好的接口）。所以只是一些公共类型的 IList、ICollection、IDictionary、IEnumerable 。数千导致您的消费者类只是等待接口而不是具体类，因此您可以在稍后阶段更改具体实现，而不会破坏您的公共合同（由于性能原因，请使用 List 代替） LinkedList<> 的列表，反之亦然）。

Answer 2

更新：

所以，严格来说这并不是新；但这个问题说服我 继续宣布 开源我已经进行了一段时间的项目（仍在进行中，但其中有一些有用的东西），其中包括一个 IArray 接口（和实现，自然地）我认为这正是您想要的：一个索引、只读、甚至协变（奖励！）界面。

一些好处：

• 它不是像 ReadOnlyCollection 这样的具体类型，因此它不会将您束缚于特定的实现。
• 它不仅仅是一个包装器（如 ReadOnlyCollection），因此它“确实是”只读的。
• 它为一些非常好的扩展方法扫清了道路。到目前为止，Tao.NET 库只有两个（我知道，很弱），但更多的库正在开发中。您也可以轻松地创建自己的 - 只需从 ArrayBase（也在库中）派生并覆盖 this[int] 和 Count< /code> 属性，就完成了。

如果这听起来很有希望，请随时检查一下并告诉我你的想法。

---

我不是 100% 清楚哪里您担心这种“语法噪音”：在您的代码中还是在调用代码中？

如果您可以容忍自己的封装代码中的一些“噪音”，那么我建议包装一个 T[] 数组并公开一个 IList ，它恰好是a ReadOnlyCollection：

class ThingsCollection
{
    ReadOnlyCollection<Thing> _things;

    public ThingsCollection()
    {
        Thing[] things = CreateThings();
        _things = Array.AsReadOnly(things);
    }

    public IList<Thing> Things
    {
        get { return _things; }
    }

    protected virtual Thing[] CreateThings()
    {
        // Whatever you want, obviously.
        return new Thing[0];
    }
}

是的，您这边有一些噪音，但这还不错。而且你暴露的界面非常干净。

另一种选择是制作自己的界面，类似IArray< T>，它包装了 T[] 并提供了仅获取索引器。然后曝光这一点。这基本上与公开 T[] 一样干净，但不会错误地传达项目可以通过索引设置的想法。

Answer 3

如果我能帮忙的话，我不会传递Lists。一般来说，我还有其他东西来管理有问题的集合，它公开了集合，例如：

public class SomeCollection
{
    private List<SomeObject> m_Objects = new List<SomeObject>();

    // ctor
    public SomeCollection()
    {
        // Initialise list here, or wot-not/
    } // eo ctor


    public List<SomeObject> Objects { get { return m_Objects; } }
} // eo class SomeCollection

所以这将是传递的对象：

public void SomeFunction(SomeCollection _collection)
{
    // work with _collection.Objects
} // eo SomeFunction

我喜欢这种方法，因为：

1）我可以在构造函数中填充我的值。当任何人新拥有SomeCollection时，它们就在那里。

2) 如果我愿意，我可以限制对底层列表的访问。在我的示例中，我将其全部公开，但您不必这样做。如果需要，您可以将其设置为只读，或者在添加之前验证列表中的添加内容。

3）很干净。在任何地方，SomeCollection 都比 List 更容易阅读。

4）如果你突然意识到你选择的集合效率低下，你可以更改底层集合类型，而不必去更改它作为参数传递的所有位置（你能想象你可能遇到的麻烦吗，比如说， 列表？）

Answer 4

我同意。 IList 与只读集合和可修改集合的结合过于紧密。 IList 应该继承自 IReadOnlyList。

转换回 IReadOnlyList 不需要显式转换。向前投射会。

1.

定义您自己的类，该类实现 IEnumerator，在新构造函数中采用 IList，具有采用索引的只读默认项属性，并且不包含任何可能允许我操纵您的列表的属性/方法。

如果您稍后希望允许像 IReadOnlyCollection 那样修改 ReadOnly 包装器，您可以创建另一个类，它是自定义 ReadOnly Collection 的包装器，并实现了 Insert/Add/Remove/RemoveAt/Clear/... 并缓存这些更改。

2.

使用 ObservableCollection/ListViewCollection 并制作自己的自定义 ReadOnlyObservableCollection 包装器，如 #1 中所示，不实现添加或修改属性和方法。

ObservableCollection 可以绑定到 ListViewCollection，这样对 ListViewCollection 的更改不会被推回 ObservableCollection。但是，如果您尝试修改集合，原始 ReadOnlyObservableCollection 会引发异常。

如果您需要向后/向前兼容性，请创建两个继承这些类的新类。然后实现 IBindingList 并将 CollectionChanged 事件（INotifyCollectionChanged 事件）处理/转换为适当的 IBindingList 事件。

然后，您可以将其绑定到较旧的 DataGridView 和 WinForm 控件以及 WPF/Silverlight 控件。

Answer 5

Microsoft 创建了集合指南 这份文件内容丰富，列出了该做和不该做的事情，可以解决您的大部分问题。

这是一个很长的列表，所以这里是最相关的：

比起数组，更喜欢集合。

请勿在公共 API 中使用 ArrayList 或 List。 （公共属性、公共参数和公共方法的返回类型）

请勿在公共 API 中使用哈希表或字典。

请勿在公共 API 中使用弱类型集合。

请尽可能使用最不专业的类型作为参数类型。大多数以集合作为参数的成员都使用 IEnumerable 接口。

避免仅使用 ICollection 或 ICollection 作为参数来访问 Count 属性。

请使用 ReadOnlyCollection（ReadOnlyCollection 的子类），或者在极少数情况下使用 IEnumerable 作为表示只读集合的​​属性或返回值。

正如最后一点所述，您不应该像您建议的那样避免 ReadOnlyCollection。对于公共成员来说，这是一种非常有用的类型，可以告知消费者他们正在访问的集合的限制。