创建封装通用集合的类有缺点吗？

Question

我的（C# 3.0 .NET 3.5）应用程序的一部分需要维护多个字符串列表。毫不奇怪，我将它们声明为 List 并且一切正常，这很好。

这些列表中的字符串实际上（并且始终）是基金 ID。我想知道是否更明确地更能揭示意图，例如：

public class FundIdList : List<string> { }

……这也有效。无论是在技术上还是在哲学上，这有什么明显的缺点吗？

Answer 1

我将从另一个方向开始：将字符串包装到名为 FundId 的类/结构中。我认为，这样做的好处比通用列表与专用列表更大。

1. 您的代码变得类型安全：您将表示其他内容的字符串传递到需要基金标识符的方法的范围要小得多。
2. 您可以将构造函数中有效的字符串限制为 FundId，即强制执行最大长度，检查代码是否采用预期格式 &c。
3. 您可以添加与该类型相关的方法/函数。例如，如果以“I”开头的基金代码是内部基金，您可以添加一个名为 IsInternal 的属性来正式说明这一点。

至于 FundIdList，拥有这样一个类的优点类似于上面针对 FundId 的第 3 点：您可以挂钩对 FundId 列表进行操作的方法/函数（即聚合函数）。如果没有这样的地方，您会发现静态帮助器方法开始在整个代码中或在某些静态帮助器类中出现。

Answer 2

列表>>没有虚拟或受保护的成员 - 此类类几乎永远应该被子类化。另外，虽然您可能需要 List 的完整功能，但如果您这样做 - 创建这样的子类有什么意义吗？

子类化有很多缺点。如果您将本地类型声明为 FundIdList，那么您将无法通过使用 linq 和 .ToList 等方式对其进行分配，因为您的类型更加具体。我见过人们决定在此类列表中需要额外的功能，然后将其添加到子类列表类中。这是有问题的，因为 List 实现会忽略此类额外位，并且可能违反您的约束 - 例如，如果您要求唯一性并声明新的 Add 方法，则任何简单（合法）向上转换为 List 的人通过将列表作为参数传递的实例，这样键入的将使用默认列表添加，而不是新的添加。您只能添加功能，而不能删除它 - 并且没有需要子类化才能利用的受保护或虚拟成员。

因此，您无法真正添加任何使用扩展方法无法添加的功能，并且您的类型不再完全兼容，这限制了您可以对列表执行的操作。

我更喜欢声明一个包含字符串的 struct FundId 并实现您需要的有关该字符串的任何保证，然后使用 List 而不是 List< ;字符串>。

最后，您真的是指 List<> 吗？ 我看到很多人使用 List<> 来处理 IEnumerable的内容。 > 或普通数组更合适。在 API 中公开您的内部 List 特别棘手，因为这意味着任何 API 用户都可以添加/删除/更改项目。即使您首先复制列表，这样的返回值仍然具有误导性，因为人们可能期望能够添加/删除/更改项目。如果您没有在 API 中公开 List，而只是将其用于内部簿记，那么声明和使用不添加任何功能的类型就没那么有趣了，仅文档。

结论

仅将 List<> 用于内部，如果使用，请勿对其进行子类化。如果您想要一些显式类型安全性，请将 string 包装在结构体中（而不是类，因为结构体在这里更高效并且具有更好的语义：空 FundId 和一个空字符串，对象相等和哈希码按预期与结构一起工作，但需要为类手动指定）。最后，如果您需要支持枚举，或者如果您还需要索引，请公开 IEnumerable<>，使用简单的 ReadOnlyCollection<> 包装列表，而不是让 API 客户端摆弄内部位。如果您确实需要可变列表 API，ObservableCollection<> 至少可以让您对客户端所做的更改做出反应。

Answer 3

就我个人而言，我会将其保留为 List，或者可能创建一个 FundId 类来包装字符串，然后存储 List >。

List 选项将强制类型正确性，并允许您对 FundIds 进行一些验证。

Answer 4

只需将其保留为 List，您的变量名称就足以告诉其他人它正在存储 FundID。

var fundIDList = new List<string>();

我什么时候需要继承List？

如果您确实需要对基金 ID 列表执行特殊操作，请继承它。

public class FundIdList : List<string> 
{
   public void SpecialAction()
   {
      //can only do with a fund id list
      //sorry I can't give an example :(
   }
}

Answer 5

除非我希望有人对 List 尽其所能，而无需 FundIdList 进行任何干预，否则我更愿意实现 IListstring>（或者层次结构中更高的接口，如果我不关心该接口的大多数成员），并在适当的时候将调用委托给私有List。

如果我确实希望某人拥有这种程度的控制权，我可能首先会给他们一个 List 。想必您有办法确保这些字符串实际上是“基金 ID”，而当您公开使用继承时，您将无法再保证这一点。

实际上，这听起来（对于 List 来说经常如此）就像私有继承的自然情况。唉，C# 没有私有继承，所以组合是最佳选择。