Классы с коллекциями как свойства против классов Наследование коллекций

Недавно я использовал класс, который наследуется от коллекции вместо того, чтобы иметь экземпляр, созданный внутри класса, является ли это приемлемым или создает невидимые проблемы дальше по дороге? Примеры ниже для ясности:

public class Cars : List<aCar>

вместо чего-то вроде:

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

Любые мысли?

Ответы

Ответ 1

Проблема заключается в том, что ваш класс Cars по-прежнему будет иметь интерфейс, который он наследует от List, что может позволить операции, которые вам не нужны.

Ответ 2

Это зависит от конечной цели вашего класса. Если он будет работать только как ваша собственная реализация коллекции, используйте наследование. Если нет, включите коллекцию в качестве свойства. Второй вариант более универсален:

  • Поскольку вы можете наследовать только один класс, вам может потребоваться наследовать другой класс, а не коллекцию
  • Если вам нужно увидеть этот класс как коллекцию, вы можете включить свойство indexer.

Ответ 3

Я неправильно прочитал вопрос раньше.

Я бы предложил использовать композицию вместо наследования. Если вы хотите использовать все забавные вещи LINQ, обязательно реализуйте IEnumerable<T> и, возможно, даже IList<T>, но я бы не получал непосредственно от List<T>.

Если вы хотите получить материал коллекции "бесплатно", но все же сохраните контроль, вы можете использовать CollectionBase. Это все еще связывает вас с точки зрения вашего единственного выстрела в наследовании, но по крайней мере вы получаете больше контроля над тем, что происходит в коллекции.

Ответ 4

Если вы хотите, чтобы ваш класс Cars действовал так же, как List, и имел те же методы, что и не так уж плохо. Вы просто проистекаете из этого, и все готово. Затем, если вы хотите добавить какие-либо дополнительные функции, вы можете просто объявить эти методы, и все готово. Тем не менее, теперь вы привязаны к списку, и если список изменяется каким-либо нежелательным образом, вы ввернуты.

Если вы сделаете вместо него составной класс и создаете экземпляр List внутри класса, вам нужно только tp разоблачить методы List, которые вы хотите открыть. Но это означает, что вы также должны повторять их.

Ответ 5

Если цель класса состоит в том, чтобы добавить дополнительную функциональность к стандартной коллекции, я бы наследовал ее из коллекции. Если коллекция является лишь частью большей картинки, это больше похоже на свойство.

Я бы, однако, рассмотрел использование Collection <T> вместо списка <T> если вам действительно не нужна функциональность в List <T> .

Ответ 6

Требуется ли класс "Автомобили"? Имеет некоторые дополнительные функции, чем "Список"? Если нет, вы должны использовать "Список" (или лучше "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
}