这里有很多很好的答案，但我想谈谈我没有提到的东西：面向对象的设计是关于增强对象的能力。

您希望将所有规则、附加工作和内部细节封装在适当的对象中。以这种方式，与此交互的其他对象不必担心这一切。事实上，您希望更进一步，积极防止其他对象绕过这些内部。

从列表继承时，所有其他对象都可以将您视为列表。他们可以直接访问添加和删除玩家的方法。你会失去控制；例如：

假设你想通过了解球员是退役、辞职还是被解雇来区分球员何时离开。您可以实现一个RemovePlayer方法，该方法采用适当的输入枚举。然而，通过从List继承，您将无法阻止对Remove、RemoveAll甚至Clear的直接访问。结果，你实际上取消了足球队课程的资格。

---

关于封装的其他想法。。。您提出了以下问题：

这使我的代码变得不必要地冗长。我现在必须调用my_team.Players.Count而不是my_team.Count。

你是对的，这对于所有使用你团队的客户来说都是不必要的冗长。然而，这个问题与你将名单球员暴露给所有人的事实相比是很小的，这样他们就可以在没有你同意的情况下玩弄你的球队。

你接着说：

这显然没有任何意义。足球队没有球员名单。这是球员名单。你不会说“约翰·麦克足球先生加入了SomeTeam的球员”。你说“John加入了SomeTeam”。

第一点你错了：去掉“列表”这个词，很明显一支球队确实有球员。然而，你用第二个击中了要害。你不希望客户端调用ateam.Players.Add（…）。你确实希望他们调用ateam.AddPlayer（…），而你的实现（可能还有其他事情）会在内部调用Players.Add（…）。

---

希望您能够看到封装对于增强对象的能力是多么重要。您希望让每个类都能很好地完成其工作，而不必担心其他对象的干扰。

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

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

什么时候可以接受？

引用Eric Lippert的话：

当您构建扩展List<T>机制的机制时。

例如，您厌倦了IList＜T＞中缺少AddRange方法：

public interface IMoreConvenientListInterface<T> : IList<T>
{
    void AddRange(IEnumerable<T> collection);
}

public class MoreConvenientList<T> : List<T>, IMoreConvenientListInterface<T> { }

序列化问题

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的完整工作实现

我肮脏的秘密：我不在乎别人说什么，我也这么做。.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
{
    ...
}