如果您的类用户需要List拥有的所有方法和财产，您应该从中派生类。如果他们不需要，请将List括起来，并为类用户实际需要的方法制作包装器。

这是一个严格的规则，如果你编写了一个公共API，或者其他很多人都会使用的代码。如果你有一个很小的应用程序，并且开发者不超过2个，你可以忽略这个规则。这将为您节省一些时间。

对于小型应用程序，您也可以考虑选择另一种不那么严格的语言。Ruby、JavaScript——任何允许您编写更少代码的东西。

我肮脏的秘密：我不在乎别人说什么，我也这么做。.NET Framework以“XxxxCollection”（我头上的例子是UIElementCollection）传播。

那么，是什么阻止了我说：

team.Players.ByName("Nicolas")

当我发现它比

team.ByName("Nicolas")

此外，我的PlayerCollection可能会被其他类使用，如“俱乐部”，而不需要任何代码重复。

club.Players.ByName("Nicolas")

昨天的最佳实践可能不是明天的最佳实践。大多数最佳做法背后没有任何原因，大多数只是社区之间的广泛共识。与其问社区，当你这样做时，它是否会责怪你，不如问问自己，什么更容易阅读和维护？

team.Players.ByName("Nicolas") 

or

team.ByName("Nicolas")

真正地你有什么疑问吗？现在，您可能需要处理其他技术限制，这些限制会阻止您在实际用例中使用List<T>。但不要添加不应该存在的约束。如果微软没有记录原因，那么这无疑是一个“最佳实践”。

虽然我没有像大多数答案那样进行复杂的比较，但我想分享一下处理这种情况的方法。通过扩展IEnumerable<T>，您可以允许Team类支持Linq查询扩展，而无需公开List<T>的所有方法和财产。

class Team : IEnumerable<Player>
{
    private readonly List<Player> playerList;

    public Team()
    {
        playerList = new List<Player>();
    }

    public Enumerator GetEnumerator()
    {
        return playerList.GetEnumerator();
    }

    ...
}

class Player
{
    ...
}

设计>实施

您公开的方法和财产是一个设计决策。您从中继承的基类是一个实现细节。我觉得回到从前是值得的。

对象是数据和行为的集合。

因此，您的第一个问题应该是：

这个对象在我创建的模型中包含哪些数据？该对象在该模型中表现出什么行为？这在未来会发生什么变化？

记住，继承意味着“isa”（是a）关系，而组合意味着“hasa”（hasa）关系。在您的视图中选择适合您的情况的应用程序，记住随着应用程序的发展，事情可能会走向何方。

考虑在考虑具体类型之前先考虑界面，因为有些人发现这样更容易将大脑置于“设计模式”。

这并不是每个人在日常编码中都有意识地做到的。但是，如果你在考虑这类话题，你就在踩设计的水。意识到这一点可以让人解放。

考虑设计规范

看看MSDN或Visual Studio上的List<T>和IList<T>。查看它们公开了哪些方法和财产。在你看来，这些方法都像是有人想对足球队做的吗？

足球队逆转（）对你有意义吗？footballTeam.ConvertAll<TOutput>（）看起来像你想要的吗？

这不是一个技巧问题；答案可能真的是“是”。如果您实现/继承List＜Player＞或IList＜Player＞，您将无法摆脱它们；如果这对你的模型很理想，那就去做吧。

如果您决定是，这是有意义的，并且您希望您的对象可以作为玩家的集合/列表（行为）处理，因此您希望实现ICollection＜Player＞或IList＜Player＞

class FootballTeam : ... ICollection<Player>
{
    ...
}

如果您希望您的对象包含玩家（数据）的集合/列表，并且因此希望该集合或列表是属性或成员，那么一定要这样做

class FootballTeam ...
{
    public ICollection<Player> Players { get { ... } }
}

你可能会觉得，你希望人们只能列举一组玩家，而不是数数、添加或删除他们。IEnumerable<Player>是一个非常有效的选择。

您可能会觉得这些接口在您的模型中根本没有用处。这是不太可能的（IEnumerable＜T＞在许多情况下都很有用），但它仍然是可能的。

任何人如果试图告诉你其中一个在任何情况下都是绝对错误的，那就是误入歧途。任何人试图告诉你在任何情况下都是绝对正确的，都是被误导的。

转到实施

一旦您决定了数据和行为，就可以决定实施。这包括通过继承或组合依赖于哪些具体类。

这可能不是一个很大的步骤，人们经常将设计和实现混为一谈，因为很有可能在一两秒钟内在脑海中完成所有这些，然后开始打字。

思想实验

一个人为的例子：正如其他人所提到的，一支球队并不总是“只是”一批球员。你有为球队收集比赛分数吗？在你的模式中，球队是否可以与俱乐部互换？如果是这样的话，如果你的球队是一个球员的集合，也许它也是一个员工的集合和/或分数的集合。然后你会得到：

class FootballTeam : ... ICollection<Player>, 
                         ICollection<StaffMember>,
                         ICollection<Score>
{
    ....
}

尽管是设计，但在C#中，此时无论如何都无法通过从List<t>继承来实现所有这些，因为C#“仅”支持单个继承。（如果你在C++中尝试过这种浮夸，你可能会认为这是一件好事。）通过继承实现一个集合，通过组合实现一个，可能会感觉很脏。而Count等财产会让用户感到困惑，除非显式实现ILIst<Player>.Count和ILIst<StaffMember>.Cunt等，否则它们只会让人感到痛苦，而不会让人感到困惑。你可以看到这是怎么回事；沿着这条路思考时的直觉很可能会告诉你，朝着这个方向前进是错误的（无论对错，如果你这样做，你的同事也可能会这样做！）

简短的回答（太迟了）

关于不从集合类继承的准则不是C#特定的，您可以在许多编程语言中找到它。这是公认的智慧，而不是法律。一个原因是，在实践中，在可理解性、可实现性和可维护性方面，组合通常被认为优于继承。在现实世界/领域对象中，找到有用的、一致的“hasa”关系比找到有用的和一致的“isa”关系更常见，除非你深入抽象，尤其是随着时间的推移和代码中对象的精确数据和行为的改变。这不应该导致您总是排除从集合类继承；但它可能是暗示性的。

当他们说List<T>是“优化的”时，我想他们想说的是，它没有像虚拟方法那样昂贵的功能。所以问题是，一旦在公共API中公开List<T>，就失去了执行业务规则或稍后自定义其功能的能力。但是，如果您在项目内部使用这个继承的类（而不是作为API潜在地暴露给成千上万的客户/合作伙伴/其他团队），那么如果它节省了您的时间，并且它是您想要复制的功能，那就没问题了。从List<T>继承的优点是，您消除了许多在可预见的将来永远无法定制的哑包装器代码。此外，如果您希望您的类在API的生命周期内显式地具有与List<T>完全相同的语义，那么它也可以。

我经常看到很多人做大量的额外工作，只是因为FxCop规则这么说，或者有人的博客说这是一种“糟糕”的做法。很多时候，这将代码转化为设计模式palooza的怪异。与许多准则一样，将其视为可能存在例外的准则。

序列化问题

One aspect is missing. Classes that inherit from List can't be serialized correctly using XmlSerializer. In that case DataContractSerializer must be used instead, or an own serializing implementation is needed.

public class DemoList : List<Demo>
{
    // using XmlSerializer this properties won't be seralized
    // There is no error, the data is simply not there.
    string AnyPropertyInDerivedFromList { get; set; }     
}

public class Demo
{
    // this properties will be seralized
    string AnyPropetyInDemo { get; set; }  
}

进一步阅读：当类从List继承时，XmlSerializer不会序列化其他属性

改用IList

我个人不会继承List，而是实现IList。Visual Studio将为您完成这项工作，并创建一个完整的工作流程。看这里：如何获得IList的完整工作实现