将集合作为属性的类与继承集合的类

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

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

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

我以前读错了这个问题。

我建议使用组合而不是继承。如果您希望能够使用所有的时髦的Linq东西,那么一定要实现 IEnumerable<T> 甚至可能 IList<T> -但我不会从 List<T> 直接。

如果你 做 想“免费”获得收藏资料,但仍保留控制权,您可以使用 CollectionBase . 从继承的一次尝试的角度来看,这仍然将您束缚在一起,但至少您可以更好地控制集合中发生的事情。

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

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

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

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

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

如果“汽车”类具有任何附加功能,则有两个主要场景:

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

.

public class CarList<T> : List<T> where T : Car {
    // some added functionality
}

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

public class CarList<T> : IList<T> where T : Car {
    private IList<T> innerList;
    public CarList() { this.innerList = new List<T>(); }

    // implementation of IList<T>

    // some added functionality
}