Когда создавать свой собственный класс IEnumerable

Question

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

Answer 1

Что ж, если у вас есть класс коллекции, вы не можете просто обернуть какую-то другую коллекцию, которая является Enumerable и будет возвращать именно то, что вы должны.

Тем не менее, я всегда предпочитаю использовать ключевое слово yield даже для определения перечислимого вручную. Большинство примеров людей, определяющих текущее / следующее движение, просто не знают о доходности или как ее использовать. (Однажды я реализовал перечислимый класс, определяющий Current / Move next по той же причине.)

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

Если у вас есть базовая коллекция, она также может быть коллекцией какого-то частного вложенного класса (возможно, какой-то пользовательской пары ключ-значение), которую вы не хотите публично раскрывать. Это тот случай, когда вам, возможно, придется возвращать вызов .Select, а не просто передавать существующий перечислитель (но, скорее всего, вам не нужно будет реализовывать собственный итератор).

Answer 2

Допустим, вы хотите перебирать строки файлов и не хотите загружать их все в память. Вы можете вернуть IEnumerable<string>, который будет читать следующую строку по требованию, а не загружать все в память. Я также предпочитаю использовать yield для таких ситуаций, как упомянуто @Servy.

Answer 3

Возможно ли, что эти примеры являются предварительными? Я вижу, что если бы вы не использовали непатентованные средства, вы бы были вынуждены реализовать IEnumerable и реализовать его методы.