Почему не стоит наследовать свой класс от List<T> в C#?

Почему наследование от List<T> — это плохая архитектура

Привет! Твой вопрос очень важный для понимания ООП и проектирования в C#. Давай разберем основные причины, почему наследование от List<T> считается антипаттерном.

1. Нарушение принципа "is-a" (является)

В ООП наследование должно моделировать отношение "является". Например, Dog : Animal — собака является животным. А является ли библиотека списком книг? Нет. Библиотека — это сущность, которая содержит список книг, но не является им. Это отношение "имеет" (has-a). Библиотека имеет книги, у неё есть адрес, название, часы работы — всё это не имеет отношения к списку.

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

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

var lib = new Library();
lib.Add(new Book()); // Ок
lib.Insert(0, new Book()); // Ок, но нарушает логику библиотеки
lib.RemoveAt(5); // Ок, хотя может быть недопустимо
lib.Clear(); // Ок — и все книги удалены без возможности восстановления

Ты теряешь контроль над поведением. Если в будущем захочешь добавить логирование при добавлении книги или проверку (например, "не добавлять книги с одинаковым ISBN"), тебе придется переопределять все методы, а многие из них не виртуальные (например, AddRange, InsertRange).

3. Проблемы с сериализацией и совместимостью

List<T> — это конкретная реализация. Если ты унаследуешь от неё, твой класс намертво привязывается к этой реализации. В будущем Microsoft может изменить внутреннее устройство List<T>, и твой код сломается. Также при сериализации могут возникнуть неожиданные эффекты, так как сериализатор будет обрабатывать твой класс как список.

4. Нелогичное поведение методов

Методы, которые ты не переопределял, будут вести себя по-списочному, а не по-библиотечному. Например, метод ToString() вернёт не название библиотеки, а что-то вроде "System.Collections.Generic.List`1[Book]". Метод Equals() будет сравнивать ссылки, а не содержимое библиотеки.

Правильное решение: Композиция вместо наследования

Вместо наследования используй композицию — сделай список приватным полем и реализуй только те методы, которые нужны твоей бизнес-логике:

public class Library
{
    private readonly List<Book> _books = new List<Book>();

    // Только те методы, которые нужны
    public void AddBook(Book book)
    {
        // Можно добавить проверку
        if (_books.Any(b => b.ISBN == book.ISBN))
            throw new InvalidOperationException("Книга с таким ISBN уже есть");
        
        _books.Add(book);
    }

    public bool RemoveBook(Book book)
    {
        // Можно добавить логирование
        return _books.Remove(book);
    }

    public IReadOnlyCollection<Book> Books => _books.AsReadOnly();

    public List<Book> FindByAuthor(string author)
    {
        return _books.Where(b => b.Author == author).ToList();
    }

    public int GetTotalPages()
    {
        return _books.Sum(b => b.Pages);
    }
}

Преимущества такого подхода:

• Полный контроль над тем, что можно делать с книгами
• Инкапсуляция — внутренняя реализация скрыта
• Гибкость — легко заменить List<T> на HashSet<T> или LinkedList<T> без изменения публичного API
• Понятный контракт — пользователь видит только методы, имеющие смысл для библиотеки

Если тебе всё же нужна возможность перебирать книги в цикле foreach, реализуй интерфейс IEnumerable<Book>:

public class Library : IEnumerable<Book>
{
    private readonly List<Book> _books = new List<Book>();
    
    public IEnumerator<Book> GetEnumerator() => _books.GetEnumerator();
    IEnumerator IEnumerable.GetEnumerator() => GetEnumerator();
    
    // Остальные методы...
}

Запомни золотое правило: "Предпочитай композицию наследованию" (Favor composition over inheritance). Это сделает твой код более гибким, тестируемым и поддерживаемым.

public class LoggingList<T> : List<T>
{
    public event EventHandler<T> ItemAdded;
    
    public new void Add(T item)
    {
        base.Add(item);
        ItemAdded?.Invoke(this, item);
    }
}