什么时候可以接受？

引用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> { }

class FootballTeam : List<FootballPlayer> 
{ 
    public string TeamName; 
    public int RunningTotal;
}

以前的代码意味着：一群来自街头的人踢足球，他们碰巧有一个名字。类似于：

总之，这个代码（来自m-y的答案）

public class FootballTeam
{
    // A team's name
    public string TeamName; 

    // Football team rosters are generally 53 total players.
    private readonly List<T> _roster = new List<T>(53);

    public IList<T> Roster
    {
        get { return _roster; }
    }

    public int PlayerCount
    {
        get { return _roster.Count(); }
    }

    // Any additional members you want to expose/wrap.
}

意思是：这是一支有管理层、球员、管理员等的足球队

这就是你的逻辑在图片中呈现的方式…

这让我想起了“是”与“有”的权衡。有时直接从超级类继承更容易，也更有意义。其他时候，创建一个独立的类并将继承自的类包含为成员变量更有意义。您仍然可以访问类的功能，但不绑定到接口或从类继承可能产生的任何其他约束。

你是做什么的？就像很多事情一样。。。这取决于上下文。我要使用的指南是，为了从另一个类继承，确实应该存在“是一种”关系。所以，如果你正在写一个叫BMW的课程，它可以继承自Car，因为BMW确实是一辆车。马类可以继承自哺乳动物类，因为马实际上是现实生活中的哺乳动物，任何哺乳动物功能都应该与马相关。但你能说一个团队就是一个列表吗？据我所知，这似乎不是一个真正的“是”列表。所以在本例中，我将一个List作为成员变量。

首选接口而非类

类应该避免从类派生，而是实现所需的最小接口。

继承中断封装

从类派生会破坏封装：

公开有关如何实现集合的内部详细信息声明可能不合适的接口（公共函数和财产集）

除此之外，这使得重构代码变得更加困难。

类是实现细节

类是一个实现细节，应该对代码的其他部分隐藏。简而言之，System.List是一种抽象数据类型的具体实现，现在和将来可能合适，也可能不合适。

从概念上讲，System.List数据类型被称为“List”这一事实有点转移视线。System.List＜T＞是一个可变的有序集合，它支持用于添加、插入和删除元素的摊余O（1）操作，以及用于检索元素数量或按索引获取和设置元素的O（2）操作。

接口越小，代码越灵活

在设计数据结构时，界面越简单，代码就越灵活。只需看看LINQ有多强大就可以演示这一点。

如何选择接口

当你想“列出”时，你应该先对自己说：“我需要代表一批棒球运动员”。假设你决定用一个类来建模。您首先应该做的是决定这个类需要公开的接口的最小数量。

可以帮助指导此过程的一些问题：

我需要计数吗？如果没有，则考虑实施IEnumerable＜T＞此集合在初始化后是否会更改？如果没有，请考虑IReadonlyList＜T＞。我可以通过索引访问项目是否重要？考虑ICollection＜T＞我向集合中添加项目的顺序是否重要？也许是ISet＜T＞？如果您确实想要这些东西，那么继续执行IList＜T＞。

这样，您就不会将代码的其他部分与棒球运动员集合的实现细节相耦合，只要您尊重接口，您就可以自由更改实现方式。

通过采用这种方法，您将发现代码变得更容易阅读、重构和重用。

避免煮沸板的注意事项

在现代IDE中实现接口应该很容易。右键单击并选择“Implement Interface”。然后，如果需要，将所有实现转发给成员类。

也就是说，如果你发现你正在编写大量的样板，这可能是因为你暴露的函数比你应该暴露的更多。这也是你不应该从类继承的原因。

您还可以设计对您的应用程序有意义的较小接口，也许只需要几个助手扩展函数就可以将这些接口映射到您需要的任何其他接口。这是我在LinqArray库的IArray接口中采用的方法。

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

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

虽然我没有像大多数答案那样进行复杂的比较，但我想分享一下处理这种情况的方法。通过扩展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
{
    ...
}