Какие интерфейсы и типы для отложенного выполнения вы знаете в C#?

Давай разберёмся с этой ленивой хуйнёй в C#, а то народ путается, как последние идиоты. Сидит, материализует коллекции раньше времени, а потом орёт, что память кончилась. Ну блядь, думать же надо!

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

1. IEnumerable<T> и IQueryable<T> — классика жанра

• IEnumerable<T> — это, блядь, основа основ. Когда ты делаешь Where, Select и прочую хуйню, ничего на самом деле не происходит. Вообще. Ни-ху-я. Просто строится план действий, как у шпиона перед миссией.

  var numbers = Enumerable.Range(1, 10); // Тишина. Пиздец как тихо.
  var evenNumbers = numbers.Where(n => n % 2 == 0); // Всё ещё тихо. Просто записали в блокнотик: "отфильтровать чётные".
  // А ВОТ ТУТ-ТО ВСЁ И НАЧИНАЕТСЯ!
  foreach (var num in evenNumbers) { Console.WriteLine(num); } // Пошла жара! Цикл запустился — фильтрация пошла.
  // Или вот так, чтоб наверняка:
  var list = evenNumbers.ToList(); // Это команда "пли!" — всё, хуярь всё в память сейчас же!

  Запомни: пока не начал перебирать (foreach) или не вызвал ToList(), ToArray(), Count() — всё это просто сказки на ночь. Выполнения ноль.

• IQueryable<T> — это уже для крутых ребят, которые с базами данных работают. Он тоже ленивый, но хитрый, как жопа с ушами. Он не фильтрует в памяти, он строит SQL-запрос и ждёт команды.

  // Допустим, Entity Framework
  var query = dbContext.Users
                      .Where(u => u.Age > 18) // Никакого SQL! Просто дерево выражений.
                      .OrderBy(u => u.Name); // Всё ещё тихо.
  // А вот теперь — БД, внимание!
  var adultUsers = query.ToList(); // Вжух! И пошёл `SELECT * FROM Users WHERE Age > 18 ORDER BY Name` на сервер.

  Если забыть ToList() и начать просто перебирать query в foreach, он сам материализует запрос. Но лучше явно, а то потом удивляешься, почему десять запросов подряд улетело.

2. Lazy<T> — для тяжёлых и дорогих объектов

Вот представь: у тебя есть класс, который подключается к космическому спутнику, качает погоду с Марса и ещё кофе варит. Создавать его сразу при старте программы — идиотизм. Вдруг пользователю только калькулятор нужен?

На помощь приходит Lazy<T>. Объект создастся только тогда, когда ты впервые потрогаешь его свойство .Value. И только один раз — потом будет возвращаться уже созданный.

public class ExpensiveService
{
    // Не "new HeavyResource()", а обёртка вокруг него. Пока спит.
    private readonly Lazy<HeavyResource> _resource = 
        new Lazy<HeavyResource>(() => new HeavyResource());

    public void Process()
    {
        // Внимание! Первый вызов — конструктор HeavyResource сработает тут!
        _resource.Value.DoWork(); // Создалось и работает.
        _resource.Value.DoWork(); // А тут уже используется готовый экземпляр.
    }
}

И да, он по умолчанию потокобезопасный, можешь дергать .Value из десяти потоков — создастся один раз аккуратно. Красота, ёпта!

3. IObservable<T> vs IEnumerable<T> — вытягивай или подставляйся

Тут философия, блядь, целая.

• IEnumerable (Pull-модель): Ты — начальник. Ты говоришь: "Давай-ка следующее значение!". И тебе его выдают. Ты контролируешь скорость. Это ленивое вытягивание.
• IObservable<T> из Rx.NET (Push-модель): Ты — подписчик. Ты говоришь: "Я готов слушать события". А источник данных (например, клики мыши, сообщения из очереди) тебе их проталкивает, когда они появляются. Последовательность вычисляется и летит в тебя по мере готовности. Это тоже отложенное выполнение, но для асинхронных потоков событий. Тут не ты итератор крутишь, а на тебя данные сыпятся, как из ведра.

Итог: Не материализуй коллекции (ToList) раньше времени — память сожрёшь. Для тяжёлых объектов используй Lazy<T> — создастся когда надо. А если хочешь реагировать на потоки событий, смотри в сторону Rx.NET.

Всё, вопрос закрыт. Иди работай.