Комментарии 25
Мне, как человеку далекому (слава Богу!) от .net, ужасно непонятно, как из foreach можно написать целую статью, причем так, что ее осилить-то можно с трудом.
Или я чего-то не понимаю, или это все overcomplicated.
Если б я писал на .net, я бы использовал более простые конструкции без такого количества подводных камней. А если для того, чтобы использовать foreach вместо for надо знать 50 страниц мануала — а не ну ли его нафиг?
Имхо очевидность и легкочитаемость кода важнее, чем удобство его написания.
Или я чего-то не понимаю, или это все overcomplicated.
Если б я писал на .net, я бы использовал более простые конструкции без такого количества подводных камней. А если для того, чтобы использовать foreach вместо for надо знать 50 страниц мануала — а не ну ли его нафиг?
Имхо очевидность и легкочитаемость кода важнее, чем удобство его написания.
Статья не столько о foreach, сколько о Duck Typing в LINQ.
А тот факт, что foreach поддерживает утипизацию, в основном так и остается лишь «любопытным фактом» и в отрыве от IEnumerable используется крайне редко.
А тот факт, что foreach поддерживает утипизацию, в основном так и остается лишь «любопытным фактом» и в отрыве от IEnumerable используется крайне редко.
Вы просто «чего-то не понимаете». Статья показывает особенности реализации foreach, который сделан через некоторый грязный хак, и поясняет, почему может возникать ошибка, когда в процессе рефакторинга foreach заменяется на LINQ выражение.
Также показывается как можно обойти эту ошибку и как вообще добавить «истиный» duck typing в программу. Это уже на мой взгляд лишнее ( вернее информация которая нужна будет только если захотите использовать). А вот про хак foreach знать надо.
В конце концов все такие статьи объясняют принципы внутренних механизмов. Это как с автомобилем — можно купить права и жать на две педали, а можно разбираться в принципах работы ДВС, тормозной системы, электронного управления в авто и прочих деталях.
Жаль только что знание этого в отношении автомобиля не позволяет ездить быстрей, маневренней и менее аварийно. А в языках программирования — позволяет.
Также показывается как можно обойти эту ошибку и как вообще добавить «истиный» duck typing в программу. Это уже на мой взгляд лишнее ( вернее информация которая нужна будет только если захотите использовать). А вот про хак foreach знать надо.
В конце концов все такие статьи объясняют принципы внутренних механизмов. Это как с автомобилем — можно купить права и жать на две педали, а можно разбираться в принципах работы ДВС, тормозной системы, электронного управления в авто и прочих деталях.
Жаль только что знание этого в отношении автомобиля не позволяет ездить быстрей, маневренней и менее аварийно. А в языках программирования — позволяет.
>Жаль только что знание этого в отношении автомобиля не позволяет ездить быстрей, маневренней и менее аварийно. А в языках программирования — позволяет.
Извините, а о каких задачах идет речь? Не для кого ни сикрет какого плана разрабатываются приложения на java и C#. Тут уже пробегали примеры кода govnokod.ru/1071
В сложном приложении сложно уйти от таких перлов. Представляете, что если в такой треш намешать еще и linq и лямбды и вообще все возможности C#?
Дискламер. Я не против развития языков и всяких фичей. Я и сам любитель всяких таких штук. Но я правда не понимаю куда это можно реально вкрутить. Точнее что за реальные такие задачи могут быть.
Извините, а о каких задачах идет речь? Не для кого ни сикрет какого плана разрабатываются приложения на java и C#. Тут уже пробегали примеры кода govnokod.ru/1071
В сложном приложении сложно уйти от таких перлов. Представляете, что если в такой треш намешать еще и linq и лямбды и вообще все возможности C#?
Дискламер. Я не против развития языков и всяких фичей. Я и сам любитель всяких таких штук. Но я правда не понимаю куда это можно реально вкрутить. Точнее что за реальные такие задачи могут быть.
ИМХО, в этой статье интересно не столько то, куда эту фичу можно вкрутить прямо сейчас, а именно подробности конкретной реализации конкретного языка.
Я несколько раз сталкивался с утиной типизацией foreach, но никогда руки не доходили разобраться и провести границу — так где же так типизировать можно, а где нельзя. А тут человек разобрал проблему и поигрался с кодом, наглядно показав как это работает. Именно поэтому статья и показалась мне интересной для перевода.
Я несколько раз сталкивался с утиной типизацией foreach, но никогда руки не доходили разобраться и провести границу — так где же так типизировать можно, а где нельзя. А тут человек разобрал проблему и поигрался с кодом, наглядно показав как это работает. Именно поэтому статья и показалась мне интересной для перевода.
> Не для кого ни сикрет какого плана разрабатываются приложения на java и C#.
Плохо можно писать на любом языке.
Плохо можно писать на любом языке.
>Плохо можно писать на любом языке.
Не бывает «хорошего» интерпрайз-кода, таковы изменчивые требования бизнеса. Я сам java кодер. В свободное от работы время ковыряюсь с Haskell и Scheme. Так что все эти языковые фишки меня уже не приводят в щенячий восторг как раньше=) Но я так и не придумал реальных задач для всех этих крутых приемов. А дергалку БД я и на отсталой жаве налабаю.
Не бывает «хорошего» интерпрайз-кода, таковы изменчивые требования бизнеса. Я сам java кодер. В свободное от работы время ковыряюсь с Haskell и Scheme. Так что все эти языковые фишки меня уже не приводят в щенячий восторг как раньше=) Но я так и не придумал реальных задач для всех этих крутых приемов. А дергалку БД я и на отсталой жаве налабаю.
Правильная архитектура и дополнительные уровни абстракции позволяют делать неплохой enterprise-код. Не идеальный конечно, но идеального ничего не бывает — всегда можно сделать лучше.
Нет ничего военного ни в generic, ни в делегатах и ивентах, ни в лямдах, ни в extension methods, ни в linq, ни в dynamic. Можно от всего этого отказаться и писать на сишарпе первой версии, надеясь что качество кода станет лучше, но я бы не стал. Многие возможности сишарпа, которые еще недавно вызывали много скепсиса, стали привычными настолько, что когда пишешь на той же джаве, всего этого добра здорово не хватает, как не хватает, например, решарпера в обычной студии.
Это не нужно «реально вкручивать», знание этой особенности позволит не допускать глупых ошибок. Например полагать что все коллекции вокруг которых работает foreach подходят как источники для linq — наивно. Пример это демонстрирует.
Добавление query comprehension сильно улучшает читабельность кода, с этим даже спорить не стоит. В примере показывается как можно добавить эту фичу для источников, которые не IEnumerable. Задача рефакторинга для вас реальная? Устроит ответ?
Добавление query comprehension сильно улучшает читабельность кода, с этим даже спорить не стоит. В примере показывается как можно добавить эту фичу для источников, которые не IEnumerable. Задача рефакторинга для вас реальная? Устроит ответ?
>Задача рефакторинга для вас реальная?
Вполне. Но о читабельности кода стоит говорить когда есть какие-то гарантии его корректности=) Лично для меня это более интересный вопрос. А так да, очень забавный этот Linq, и статья интересная.
Вполне. Но о читабельности кода стоит говорить когда есть какие-то гарантии его корректности=) Лично для меня это более интересный вопрос. А так да, очень забавный этот Linq, и статья интересная.
немного не понял — вы утверждаете что скомпилированное query comprehension может быть некорректным или что?
Я имел ввиду другое то, что «рюшечки» дело последнее, хоть и не менее важное чем все остальные. А вот решение первостепенных задач на .NET встретишь реже чем очередную красоту в коде. Никак ловкий маркетинговый ход MS=)
не знаю почему для вас читабельность кода это рюшечки — ведь даже в решениях первостепенных задач код должен быть читабельным.
А какие конкретно первостепенные для вас задачи на дотнете труднорешаемы, что вы так отдельно это выделяете?
PS читающие — не минусуйте без повода товарища, вроде диалог идет. а то уподобляться будем толпе…
А какие конкретно первостепенные для вас задачи на дотнете труднорешаемы, что вы так отдельно это выделяете?
PS читающие — не минусуйте без повода товарища, вроде диалог идет. а то уподобляться будем толпе…
>А какие конкретно первостепенные для вас задачи на дотнете труднорешаемы
А тут не в дотнете дело. Вообще прикладухи. То, что я читаю в книжках/блоках это прям утопия какая-то. А то, что я вижу на практике это примерно вот: govnokod.ru/1071. И как не крутись любой более-менее сложный проект обрастает таким ужасом. Скажите кривая архитектура. А где же она не кривая? Я вообще ни разу не видел в реальном проекте реализацию бизнес-логики с помощью модели предметной области: martinfowler.com/eaaCatalog/domainModel.html. Сплошная процедурщина, это в ОО языках то! Может где-то и есть такие умные люди у которых все круто, красиво и объектно и потраченный бюджет при этом не стремится к бесконечности, но я лично таких не встречал. Неужели и я и все вокруг как назло глупые?
А тут не в дотнете дело. Вообще прикладухи. То, что я читаю в книжках/блоках это прям утопия какая-то. А то, что я вижу на практике это примерно вот: govnokod.ru/1071. И как не крутись любой более-менее сложный проект обрастает таким ужасом. Скажите кривая архитектура. А где же она не кривая? Я вообще ни разу не видел в реальном проекте реализацию бизнес-логики с помощью модели предметной области: martinfowler.com/eaaCatalog/domainModel.html. Сплошная процедурщина, это в ОО языках то! Может где-то и есть такие умные люди у которых все круто, красиво и объектно и потраченный бюджет при этом не стремится к бесконечности, но я лично таких не встречал. Неужели и я и все вокруг как назло глупые?
НЛО прилетело и опубликовало эту надпись здесь
Видать сильно зацепил тот пример, или это вы постили?
Может вы просто не туда смотрите (или не там работаете)? Откройте например код того же community server — domain model. Любая генерация linq2sql по правильно задизайненной бд — тоже почти domain model.
У нас в компании, например, вообще «ректальные кары» за попытки писать бизлогику и общение с бд через что-либо, кроме domain model.
Многие открытые продукты с очень даже неплохой доменной моделью.
Может вы просто не туда смотрите (или не там работаете)? Откройте например код того же community server — domain model. Любая генерация linq2sql по правильно задизайненной бд — тоже почти domain model.
У нас в компании, например, вообще «ректальные кары» за попытки писать бизлогику и общение с бд через что-либо, кроме domain model.
Многие открытые продукты с очень даже неплохой доменной моделью.
>Видать сильно зацепил тот пример, или это вы постили?
Пример не мой, просто увидел родные для взора приемы программирования=)
>Может вы просто не туда смотрите (или не там работаете)?
Может быть. Но другого я пока не нашел.
>Многие открытые продукты с очень даже неплохой доменной моделью.
О, был бы очень признателен, если накидаете ссылочек.
Пример не мой, просто увидел родные для взора приемы программирования=)
>Может вы просто не туда смотрите (или не там работаете)?
Может быть. Но другого я пока не нашел.
>Многие открытые продукты с очень даже неплохой доменной моделью.
О, был бы очень признателен, если накидаете ссылочек.
>И как не крутись любой более-менее сложный проект обрастает таким ужасом
Это вот вообще неправда, вернее нельзя так смело это утверждать.
Н-р: работаю в финтехе, пилим хороший продукт, 20 разработчиков, ещё 30 аналитиков и тестировщиков. Пара десятков модулей, 4-5 штук из их числа — по 10-20к файлов исходного кода, и ТАКОГО ужаса, как по ссылке, за более двух лет работы на проекте нигде не встретил даже близко.
Даже лютое легаси, которому уже 5-7 лет, выглядит очень прилично.
P.S. Мб мы везунчики, что нам 20% рабочего времени выделено на качество кода (целая пятница), но с таким количеством бизнес-логики как в финтехе, код по ссылке просто невозможно было бы поддерживать уже через год.
P.P.S. Дискуссия 2009 года :D Сорри за некропостинг =)
пожалуйста, пользуйтесь.
Это так сказать «джедайские» техники.
foreach вообще очень интересный оператор и о нем действительно можно много и долго разговаривать (в какой ситуации во что он скомпилируется и какую производительность будет иметь) — и мне кажется, что это здорово.
Это так сказать «джедайские» техники.
foreach вообще очень интересный оператор и о нем действительно можно много и долго разговаривать (в какой ситуации во что он скомпилируется и какую производительность будет иметь) — и мне кажется, что это здорово.
Нубство — это плохо…
Спасибо, весьма занятная статья.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Возвращаясь к конструкции foreach с Duck Typing для LINQ