这里有一些很好的答案。我将向他们补充以下几点。
什么是表示数据结构的正确C＃方法，“逻辑上”（也就是说，“对人类而言”）只是一个带有一些花哨的东西的列表？
让任何十位熟悉足球存在的非计算机编程人员来填补空白：
足球队是_____的一种特殊类型
难道 有人 说“有一些花俏的足球运动员名单”，还是他们都说“运动队”或“俱乐部”或“组织”？您认为足球队是 一种特殊的球员名单，
这在您的人心中和您的人心中都是存在的。
List<T>是一种 机制 。足球队是一个 业务对象 ，即代表该程序 业务领域 中某些概念的对象。不要混那些！足球队 是一种 球队。它
有一个 名册，一个名册 是一个球员名单 。名册不是 特定的球员名单 。名册 是
球员名单。因此，让一个名为属性
Roster这是一个
List<Player>。并使其
ReadOnlyList<Player>当你在它，除非你相信大家谁知道一个足球队获得从名册上删除的球员。
从
List<T>永远继承是不可接受的吗？
谁不能接受？我？没有。
什么时候可以接受？
在构建 扩展该List<T>
机制的机制时。
程序员在决定是否继承时必须考虑什么
List<T>？
我是在建立 机制 还是 业务对象 ？
但这是很多代码！我能从所有工作中得到什么？
您花了更多时间输入问题，以至于需要为相关成员编写转发方法
List<T>50次以上。您显然不怕冗长，在这里我们谈论的代码很少。这是几分钟的工作。
更新
我再三考虑一下，还有另一个原因不将足球队建模为球员名单。实际上，将足球队建模为也 有
球员名单可能不是一个好主意。与团队/有球员名单的问题是，你所得到的是一个 快照 的球队 在某个时刻
。我不知道您在这堂课上的业务案例是什么，但是如果我有一堂代表足球队的课，我想问一下这样的问题：“有多少海鹰球员因2003年至2013年受伤而缺席比赛？”
还是“以前为另一支球队效力的丹佛球员在码数上的同比增长最大？” 或“
今年猪头人一路走？ ”
就是说，在我看来，一支足球队的模型被很好地模拟为 历史事实的集合， 例如球员被招募，受伤，退休等 的历史事实
。显然，目前的球员名册是一个重要的事实，应该很重要。居中，但您可能还需要对这个对象进行其他有趣的操作，这些操作需要更多的历史视角。
