Использование итераторов foreach?

Question

[Николай Кузык]

Привет всем , суть вопроса :
есть цикл Foreach который собствено делает итерацию обьекта, кок понять почему нужно и когда нужно использовать интерфейсы с их методом GetEnumerator(); IEnumerable, IEnumerator, IEnumerable и IEnumerator
и в чем собствено разница использования этих интерфейсов вместе с циклом ? почему я не могу просто использовать цикл не прибегая к ним ?

Answer 1

[cicatrix]

Интерфейсы нужны для того, чтобы с вашими собственными классами могли работать другие классы.
Например, вы реализовали собтсвенную коллекцию объектов со своей странной логикой. Допустим, вы хотите, чтобы по этой коллекции можно было бы пройтись циклом foreach, но изначально фрейморк понятия не имеет, каким образом осуществлять итерацию объектов внутри вашей коллекции. Вот тогда вы заявляете, что ваш класс реализует интерфейс IEnumerable, и предоставляет наружу реализацию этого интерфейса. Вот тогда фреймворк уже знает, как можно перебрать все элементы коллекции.
IEnumerable реализует и массив и список и словарь и связный список, то есть для того, чтобы вы могли пройтись по какому-либо классу при помощи foreach, этот класс обязан реализовывать IEnumerable. Считайте интефейс это "соглашение о сотрудничестве" между разными классами, в котором чётко определены правила взаимодействия.

Comments

[Роман]

чтобы вы могли пройтись по какому-либо классу при помощи foreach, этот класс обязан реализовывать IEnumerable

А на что поспорим, что не обязан?

[cicatrix]

Роман, Ну просветите меня, чего я не учёл. Вот, поглядел специально:

The foreach statement repeats a group of embedded statements for each element in an array or an object collection that implements the System.Collections.IEnumerable or System.Collections.Generic.IEnumerable interface. The foreach statement is used to iterate through the collection to get the information that you want, but can not be used to add or remove items from the source collection to avoid unpredictable side effects. If you need to add or remove items from the source collection, use a for loop.

[Роман]

cicatrix, вот вам такой вам код
https://dotnetfiddle.net/RsJbIg
когда найдете там реализацию интерфейсов, сообщите.

ну а так гуглите C# утиная типизация, будите очень удивлены

[cicatrix]

Роман, да, это ровно то, о чём я писал ниже, вот прекрасно всё описано. Это баг, который разработчики C# Design group уныло выдают за фичу.

[Роман]

cicatrix, sergeyteplyakov.blogspot.ru/2012/08/duck-typing-fo... почитайте зачем это нужно было.
Это не ровно то, что вы говорили, у вас там слово обязан было, но фактически неявная реализация. Кстати один из популярных вопросов на собеседовании, что надо сделать, чтобы пройтись по коллекции Foreach.

[cicatrix]

Роман, в вашей же ссылке:

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

Что, собственно, и требовалось доказать.

Я же ссылался на свой комментарий к вашему ответу на вопрос (ниже). Но не суть. Насчёт собеседования - мне сложно судить, но по моему мнению, знание недокументированных возможностей фреймворка может приветствоваться, но не должно быть основанием для принятия решения о том, брать соискателя на работу или нет. Согласно документации, для итерации foreach класс обязан реализовывать IEnumerable или IEnumerable<T> в явном виде. Соискатель вовсе не обязан знать о том, что для foreach реализовать IEnumerable можно и не явно. Более того, это знание вредно.

[Роман]

cicatrix, Я бы сказал, наоборот полезно. Ибо бывает так, что эти хаки потом могут вылезти в вашем проекте и сломать его.

[cicatrix]

Роман, Если разработчик не знает про хак, он им и пользоваться не будет :) А на code review я бы заставил переписать с явной ссылкой на IEnumerable.

[Роман]

cicatrix, Вы читали статью Теплякова? там есть интересный пример, основывается на знании внутреннего устройства итераторов стандартных коллекций, я сам до недавнего времени не знал, что итераторы стандартных коллекций это структуры, так вот, трудно конечно в реалии придумать, зачем такое использовать, но может потом возникнуть ситуация, что долго будете думать почему так. Внутреннее устройство .net в некоторых моментах надо знать, учитывая, что вам может это помочь в решении своих проблем.

[cicatrix]

трудно конечно в реалии придумать, зачем такое использовать

Вот именно. Есть теория, где действительно можно порассуждать над особенностями реализации, а есть практика. За всё время моей работы с C# мне ни разу в голову не пришло обращаться при проходе коллекции к GetEnumerator, это, собственно, практически равнозначно собственной реализации IEnumerable.
Вопросы же быстродействия и производительности в наше время вообще остро не стоят. Если есть критический кусок кода, его проще переписать на плюсах и подключить в проект как внешний компонент, но зачастую достаточно простого рефакторинга.
В любом случае, спасибо за предоставленную информацию, я сегодня узнал про возможности неявной реализации IEnumerable. :)

[Роман]

cicatrix,

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

создатели StackOverflow с вами не согласны. Как и программисты . net, не зря они сделали в стандартных коллекциях инемераторы структурами.

[Николай Кузык]

cicatrix, спрашиваю я, узнают другие:)

[cicatrix]

Роман,

создатели StackOverflow с вами не согласны. Как и программисты . net, не зря они сделали в стандартных коллекциях инемераторы структурами.

Кто со мной не согласен? )) Прям, все как один?

Answer 2

[Роман]

Почитайте https://habrahabr.ru/post/209914/

Comments

[cicatrix]

Прочитал, но по факту, класс всё равно реализует IEnumerable, просто явно об этом не заявляет. И это говорит не в пользу тех, кто разрабатывал эту фичу в языке. Какой-то индус схалявил, а, поскольку, все тесты проходили на ура, это осталось в релизе. Не должно быть duck typing в строго типизированном языке.

Answer 3

[Станислав Макаров]

Не должно быть duck typing в строго типизированном языке.

Это не duck typing, это структурная типизация. Проверки, как вы могли заметить, выполняются во время компиляции, а не выполнения - где ж тут duck typing? А то что наследоваться не обязательно от опр. интерфейса - так что ж тут плохого? Язык даёт синтаксический сахар в виде foreach, задача компилятора - сгенерить код, содержащий вызовы определённых методов с определённой сигнатурой, не более. Это задача именно что для структурной типизации, когда компилятору без разницы что у вас там за класс и какие у него интерфейсы, лишь бы можно было сгенерировать нужный код, и это правильно.
В конце-концов шаблоны в C++ работают точно также. И for-range циклы в C++ работают похожим образом (требуют чтобы были реализованы нужные методы, или свободные функции, принимающие аргумент нужного типа). В C# советуют реализовывать интерфейс, т.к. это даёт дополнительные возможности: а) передавать объект туда, где ожидается этот интерфейс (т.к. C# всё таки в основном язык с номинативной типизацией); б) контролировать что вы не забыли ничего реализовать.

Прочитал, но по факту, класс всё равно реализует IEnumerable, просто явно об этом не заявляет.

Не соглашусь, довольно спорный момент. Номинативная типизация говорит, что если только явное заявление о том, что мы реализуем какой-то интерфейс, даёт нам отношение is-a между классом и интерфейсом. Если мы НЕ говорим, что реализуем IEnumerable, то мы его НЕ реализуем, даже если у нас там такие же методы.

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

Comments

[Роман]

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

Structural systems are used to determine if types are equivalent and whether a type is a subtype of another. It contrasts with nominative systems, where comparisons are based on the names of the types or explicit declarations, and duck typing, in which only the part of the structure accessed at runtime is checked for compatibility.

. Ну и про компилятор, он выдает ошибку, если в коллекции нет GetInumerator и если в инуменаторе нет MoveNext и Current. Кстати самый яркий пример утиной типизации в шарпе это dynamic.

[Станислав Макаров]

Роман

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

Что вы понимаете под "соответствием типов"? Соответствие структуры или соответствие имён? Это принципиальный момент.

утиной, которая требует лишь наличия соответствующих свойств, методов.

Причём проверка выполняется на этапе выполнения, а не компиляции.

Ну и про компилятор, он выдает ошибку, если в коллекции нет GetInumerator и если в инуменаторе нет MoveNext и Current.

Вот именно, компилятор. Упомянутый вами "dynamic" будет делать проверку во время компиляции? Нет конечно, он для того и добавлен в язык, чтобы откладывать проверку до момента выполнения, чтобы получить в итоге утиную типизацию.