Почему не нужно наследоваться от List<T> в C#

Обновлено: 31.10.2026 · 3 мин чтения

Нарушение принципа инкапсуляции

Класс-наследник получает весь публичный интерфейс List<T>, даже если он нужен лишь частично. Вопрос в том, как это связано с инкапсуляцией и что именно оказывается открытым.

Что такое инкапсуляция и как наследование от List её нарушает?

Инкапсуляция - это один из столпов объектно-ориентированного программирования. Она позволяет скрыть внутреннее состояние объекта и предоставить доступ к нему только через определенный интерфейс. Наследуя от List<T>, вы открываете все методы и свойства базового класса, что может привести к неожиданному использованию или изменению внутреннего состояния вашего объекта. Для иллюстрации рассмотрим следующий пример:

public class CustomCollection<T> : List<T> {
    // Предположим, вы хотите добавить дополнительную логику при добавлении элементов.
    public new void Add(T item) {
        // Добавляемая логика...
        base.Add(item);
    }
}

var myCollection = new CustomCollection<int>();
myCollection.Add(1); // Вызывает новый метод Add.
myCollection.AddRange(new [] {2, 3, 4}); // Обходит вашу дополнительную логику.

Использование AddRange напрямую позволяет обойти дополнительную логику, определенную в Add, что может привести к ошибкам или неконсистентному состоянию коллекции.

Ограничение гибкости

Наследование жёстко привязывает ваш тип к реализации списка. Посмотрим, как это мешает менять внутреннее устройство класса позже.

Как расширение List ограничивает будущие изменения?

При наследовании от List<T> вы фиксируете определенную реализацию коллекции. Если в будущем потребуется изменить базовую реализацию (например, перейти с List<T> на LinkedList<T>), это потребует значительных изменений в коде, поскольку интерфейсы и поведение этих двух типов коллекций различаются. Поддержка такого изменения может стать головной болью, особенно если ваш класс широко используется в разных частях системы.

Нецелесообразное расширение

В List<T> много методов, которые вашему классу могут не подходить. Рассмотрим, к чему приводит такой лишний набор операций.

Почему не все методы List могут быть нужны в вашем классе?

List<T> предоставляет широкий набор методов для управления коллекцией, но не все они могут быть релевантны для вашего специализированного класса коллекции. Например, представьте коллекцию только для чтения. Наследование от List<T> дает возможность модифицировать эту коллекцию, что противоречит её предполагаемому использованию.

Проблемы с сериализацией

Сериализация наследников списка часто работает не так, как ожидается. Разберём, какие сложности с этим возникают.

Как наследование от List влияет на сериализацию?

При наследовании от List<T> могут возникнуть проблемы с сериализацией, особенно если вы добавили дополнительные свойства или методы в производный класс. Сериализация может не учитывать эти дополнения, что приведет к потере данных или некорректному восстановлению состояния объекта при десериализации.

Нарушение принципа подстановки Барбары Лисков

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

Что такое LSP и как наследование от List его нарушает?

Принцип подстановки Барбары Лисков (LSP) гласит, что объекты в программе должны быть заменяемыми на экземпляры подтипов без изменения правильности выполнения программы. Наследуя от List<T>, вы рискуете нарушить этот принцип, если ваш подкласс изменяет поведение базового класса таким образом, что он больше не соответствует ожидаемому поведению List<T>.

Альтернативные способы реализации коллекций

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

Какие паттерны и подходы можно использовать вместо наследования от List?

Вместо наследования от List<T>, рекомендуется использовать композицию или делегирование. Вы можете включить приватный экземпляр List<T> в ваш класс и предоставлять только те операции, которые действительно необходимы:

public class CustomCollection<T> {
    private List<T> _list = new List<T>();

    public void Add(T item) {
        // Дополнительная логика...
        _list.Add(item);
    }

    // Остальные методы, которые вы хотите предоставить...
}

Другим подходом может быть реализация интерфейсов IEnumerable<T> или ICollection<T>, что обеспечит большую гибкость и позволит контролировать, какие операции доступны пользователям вашего класса.

Заключение
Наследование от List<T> в C# может быть соблазнительным из-за кажущейся простоты расширения функциональности. Однако, как мы увидели, такой подход может привести к ряду проблем, связанных с инкапсуляцией, гибкостью, сериализацией и нарушением принципа LSP. Использование композиции или реализации интерфейсов является более предпочтительным подходом при создании пользовательских коллекций в C#. Это обеспечивает больший контроль над поведением и интерфейсом коллекции, делая код более гибким и устойчивым к изменениям.