如果足球队有一支预备队和主力队呢？

class FootballTeam
{
    List<FootballPlayer> Players { get; set; }
    List<FootballPlayer> ReservePlayers { get; set; }
}

你将如何建模？

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

这种关系显然是有一个，而不是一个。

还是退役球员？

class FootballTeam
{
    List<FootballPlayer> Players { get; set; }
    List<FootballPlayer> ReservePlayers { get; set; }
    List<FootballPlayer> RetiredPlayers { get; set; }
}

根据经验，如果您想从集合继承，请将类命名为SomethingCollection。

你的SomethingCollection在语义上有意义吗？只有当你的类型是Something的集合时才这样做。

就足球队而言，这听起来不太对。团队不仅仅是集合。正如其他答案所指出的，一个团队可以有教练、教练等。

FootballCollection听起来像是足球的集合，也可能是足球用品的集合。TeamCollection，团队的集合。

FootballPlayerCollection听起来像是一个球员集合，如果你真的想这样做的话，它将是继承自List<FootballPlayer>的类的有效名称。

真正的列表＜FootballPlayer＞是一个非常好的类型。如果您从方法返回IList＜FootballPlayer＞，则可能是这样。

总而言之

问问你自己

X是Y吗？或者有X和Y？我的类名是什么意思？

让我改写你的问题。所以你可能会从不同的角度来看待这个问题。

当我需要代表一支足球队时，我明白这基本上是一个名字。比如：《老鹰》

string team = new string();

后来我意识到球队也有球员。

为什么我不能扩展字符串类型，以便它也包含一个玩家列表？

你的切入点是武断的。试着想想一个团队有什么（财产），而不是它是什么。

完成后，您可以查看它是否与其他类共享财产。想想遗产。

允许人们说

myTeam.subList(3, 5);

有什么意义吗？如果不是，那么它不应该是一个列表。

首先，它与可用性有关。如果使用继承，Team类将公开纯粹为对象操作而设计的行为（方法）。例如，AsReadOnly（）或CopyTo（obj）方法对团队对象没有意义。与AddRange（items）方法不同，您可能需要一个更具描述性的AddPlayers（players）方法。

如果您想使用LINQ，实现诸如ICollection＜T＞或IEnumerable＜T＞之类的通用接口将更有意义。

如前所述，合成是正确的方法。只需将玩家列表作为一个私有变量来实现。

什么时候可以接受？

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

这是一个组合与继承的经典例子。

在这种特定情况下：

球队是一个有附加行为的球员列表吗

or

球队是否是自己的一个对象，恰好包含一个球员列表。

通过扩展列表，您可以通过多种方式限制自己：

您不能限制访问（例如，阻止人员更改名册）。您可以获得所有List方法，无论您是否需要它们。如果你还想列出其他事情，会发生什么。例如，球队有教练、经理、球迷、设备等。其中一些可能是他们自己的名单。你限制了继承的选择。例如，您可能希望创建一个通用的Team对象，然后让BaseballTeam、FootballTeam等继承该对象。要从列表继承，您需要从团队继承，但这意味着所有不同类型的团队都必须对该名册进行相同的实现。

合成-包括一个对象，它给出了你想要的对象内部的行为。

继承-对象成为具有所需行为的对象的实例。

两者都有各自的用途，但这是一个明显的情况，即合成更可取。