Классы с коллекциями как свойства и классы, наследующие коллекции

Question

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

public class Cars : List<aCar>

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

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

Есть мысли?

Answer 1

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

Answer 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
}