具有集合属性的类与继承集合的类

Question

最近我使用了一个继承自集合的类，而不是在类内实例化集合，这样做是否可行或会在后面造成看不见的问题呢？以下是为了更好的理解而提供的示例：

public class Cars : List<aCar>

而不是像这样：

public class Cars
{
 List<aCar> CarList = new List<aCar>();
}

有什么想法吗？

- wwilkins

Answer 1

问题在于，您的 Cars 类仍将具有从 List 继承的接口，这可能允许您不想要的操作。

- brazzy

Answer 2

这取决于你的类的最终目的。如果它只用作集合的自己实现，请使用继承。否则，将集合包含为属性。第二个选项更加灵活：

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

- Igor Zelaya

Answer 3

我之前误读了问题。

我建议使用组合而不是继承。如果你想要使用所有花哨的LINQ东西，尽管实现IEnumerable<T>甚至IList<T> - 但我不会直接从List<T>派生。

如果你确实想要“免费”获得集合功能但仍保留控制，你可以使用CollectionBase。这仍然将你限制在继承方面，但至少你可以更多地控制集合中发生的事情。

- Jon Skeet

Answer 4

如果您希望您的Cars类像List一样运作，并具有相同的方法，那么这并不是太糟糕。您只需要从中派生出来，就可以完成了。然后，如果您想添加任何其他功能，只需声明这些方法即可。但是，现在您与List绑定在一起，如果List以任何不良方式更改，那么您就会遇到麻烦。

相反，如果您将其变成一个组合类，并在类内实例化List，那么您只需要公开您想要公开的List方法即可。但这意味着您也必须重复它们所有。

- Mike Hall

Answer 5

如果类的目的是为标准集合添加其他功能，那么我会从集合中继承。如果集合只是更大图片的一部分，那么这听起来更像是一个属性。

然而，我会考虑使用Collection而不是List，除非你真的需要List中的功能。

- Jon B

Answer 6

“Cars”类真的必要吗？它比“List”多了一些功能吗？如果没有，应该使用“List”（或更好的“IList”）。

如果“Cars”类有任何附加功能，则有两种主要情况：

• 这个类是“final”类，很少有人需要扩展它。那么这个构造是可以的。
• 这个类可能会被用作基类。那么我建议使用这个构造：

.

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
}

- TcKs