最近，我使用了一个从集合继承的类，而不是在类中实例化集合，这是可以接受的，还是会在更远处造成看不见的问题？为了清楚起见，以下示例：

而不是像：

有什么想法吗？

问题在于Cars类仍然具有它从列表继承的接口，这可能允许您不需要的操作。

这取决于你们班的最终目的。如果它只作为您自己的集合实现工作，请使用继承。如果不是，则将集合作为属性包含。第二种选择更加多样化：

• 由于只能从一个类继承，因此可能需要从另一个类继承，而不是从集合继承
• 如果需要将此类视为集合，则可以包含索引器属性。

我以前读错了这个问题。

我建议使用组合而不是继承。如果你想使用所有时髦的LINQ工具，尽可能实现IEnumerable，甚至可能实现IList，但我不会直接从List派生。

如果您确实想"免费"获取集合内容，但仍然保留控制权，那么可以使用CollectionBase。从继承的一次尝试的角度来看，这仍然将您束缚在一起，但至少您可以更好地控制集合中发生的事情。

如果类的目的是向标准集合添加附加功能，那么我将从该集合继承。如果这个集合只是一个整体的一部分，那么这听起来更像是一个属性。

但是，我会考虑使用collection而不是list除非您确实需要list中的功能。

如果你想让你的Cars类表现得像一个列表，并且拥有与之相同的方法，那就没有那么糟糕了。你只是从中得到灵感，你就完蛋了。然后，如果您想添加任何附加功能，您只需声明这些方法，就可以完成了。然而，现在你必须列出清单，如果清单以任何不受欢迎的方式改变，你就完蛋了。

当您将它改为复合类并在类中实例化列表时，您只需要tp公开您想要公开的列表方法。但这意味着你也必须重复一遍。

"汽车"课真的需要吗？除了"list"还有其他功能吗？如果没有，您应该使用"list"(或更好的"ilist")。

如果"汽车"类具有任何附加功能，则有两个主要场景：

• 这个班是"最后"班，没有很大的可能性，别人需要延长它。那么这个建筑可以吗？
• 这个类可能会用作基类。然后我建议使用这种结构：

.

如果您希望将来更灵活，您应该使用组合：