- 1
- 2
- 3
- 4
- 5
- 6
- 7
public class DataLayer
{
...
public List<Employee> GetEmployees() { ... }
public List<Department> GetDepartments() {...}
public List<Roles> GetRoles() {...}
}-
C# / Говнокод #13426
+129
Обратил внимание, что некоторые коллеги любят использовать в качестве возвращаемых типов не обычные массивы, а обязательно List<T>.
Долго гадал, что-ж такая за практика интерсная, на стеке прям несколько вопросов подрял.
Затем, обратил внимание, что все они используют в качестве основного инструмента паттерн MVC.
Проштудировав самые известные книжки по MVC, таки нашёл виновника:
http://www.ozon.ru/context/detail/id/19064535/ - Программирование на основе Microsoft ASP.NET MVC (Дино Эспозито)
Везде где только можно, всё просто обделано LIst'ами. Даже данные передаваемые во View...Запостил:
TauSigma,
15 Июля 2013
Follow us!
А вообще - я тоже всегда List<T> использовал. Почему не помню, но явно не из-за этой книжки. Возможно потому, что все остальные в конторе делали так же ;)
А что хорошего-то? Есть динамические массивы, есть статические массивы.
С чего вдруг такая нездоровая любовь к обёртке статических массивов?
Ага. А как же.
http://msdn.microsoft.com/en-us/library/9b9dty7d(v=vs.80).aspx
Array types are reference types derived from the abstract base type Array. Since this type implements IEnumerable and IEnumerable, you can use foreach iteration on all arrays in C#.
http://msdn.microsoft.com/en-us/library/system.array.aspx
Starting with the .NET Framework 2.0, the Array class implements the System.Collections.Generic.IList<T>, System.Collections.Generic.ICollection<T >, and System.Collections.Generic.IEnumerable<T > generic interfaces. The implementations are provided to arrays at run time, and therefore are not visible to the documentation build tools. As a result, the generic interfaces do not appear in the declaration syntax for the Array class, and there are no reference topics for interface members that are accessible only by casting an array to the generic interface type (explicit interface implementations). The key thing to be aware of when you cast an array to one of these interfaces is that members which add, insert, or remove elements throw NotSupportedException.
Потому без каста не получается.
В жабе кстати тоже костыльно массивы сделаны. Там так вообще нельзя.
Если массив будет в 100% использоваться для перечисления, то зачем его пихать в List<T>
(Который в итоге всё равно вызовет newarr, да ещё и Array.Resize может вызвать при не умелом использовании.)
быть может в некоторых случаях List<T> медленнее, чем массив, но я посмотрю, как вы одной строчкой добавите новый элемент не переопределяя массив =)
immutable vs mutable
> функционал List<T> и T[] сильно отличается
Без ололо-LINQ это было бы так. Но поскольку extension-методы добавляют практически всю функциональность листов, то...
LINQ'вский ToArray() тоже оригинальностью не отличается:
Но если нужен Array, а не List, то надо использовать Array. Многие этой разницы не понимают.
В IL'е это newarr, ldlen и stelem.ref.
Может быть такая проблема и есть, но явно не под тем углом, под которым вы её подняли.
Если взять за пример паттерн MVC, то передавать во View List<T> бессмысленно, т.к. данные уже должны быть подготовлены заранее, прежде чем отдавать их во View.
Дино Эспозито, когда писал свой "креатив" (а "креатива" там достаточно), этим правилом принебрёг, из этого и пошло поколение разработчиков, использущее везде где только можно List<T> без разбора.
Так или иначе работаем с массивом.
Внутри List<T>'а обычный массив. И если ему не хватает места вызывается Array.Resize(...).
Он не может быть быстрее себя самого с обёрткой.
как вы одной строчкой добавите новый элемент не переопределяя массив
Я не спорю, если массив динамический.
Но если это уже готовые данные, которые никуда ресайзить не надо, то зачем его List<T>'ом отдавать.
Это так и на остальные типы забить можно. Всё с лихвой в String влезет. Ещё и манипулировать можно как угодно.
Когда-то давно, когда я только устроился на работу и начал писать такие же методы с массивами тимлид мне вообще прямо сказал - забудь про массивы - только листы, только хардкор. В те времена как раз вышла 5-я жаба и с женериками массивы потеряли свое последнее преимущество над листами.
Я тогда его не понял, сейчас понимаю отчасти.
Просто это как привычка. Лист - хорошая штука, это ж интерфейс по сути, а там может быть что угодно - Linked или массив. Обертка - хер с ним, мы ведь итак пишем на языках со сборкой мусора и кучей оверхеда.
С массивами (в жабе) есть пара багов (нерабочие equals и hashCode) из-за которых нубам проще так и говорить - юзай лист и не думай.
Считайте это энтерпрайзом головного мозга или просто желанием сделать код универсальнее.
Как hashCode может работать в изменяемом обьекте? А откуда там equals?
Почему-то мне ЭГМ это не кажется.
Как говаривал мне когда-то один 80-летний дедушка: ум человека можно оценить по тем вопросам которые он задает.
После чего я стал думать перед тем как у него что-то спрашивать.
Не льсти себе.
Даже не умеешь читать что пишут другие люди.
Тебе не помогут ответы других людей, поскольку ты не сумеешь их понять.
Пц, почему борманда плюсуют за мой комент? Ничиво нипанимаю, тут своих плюсуют?
Я вставлял слово - 32битная питушня, 386/486-е говно. Стек говно, во всех моих портянках 64битные инты - и да, я за 32бита - круто.
> Пц, почему борманда плюсуют за мой комент? Ничиво нипанимаю, тут своих плюсуют?
Да не. Просто его утверждения противоречат словам царя, а мое про 64 бита - нет.
indexOf(), containsAll(), iterator() и проч.
O(n)
>containsAll()
Чтоэта и зачем?
> iterator()
Зачем?
Плюс не в жабе, а в ЖОПЕ
Какой еще IList?
http://msdn.microsoft.com/en-us/library/5y536ey6.aspx
Как раз джавистам глаз ничего резать не будет.
Кстати в прошлом году гугол выдавал сцылки на документацию JDK4, может с выходом 8-ой наконец-то появится JDK7?
То, что в .NET IList соответствует List, а List - ArrayList, сути дела не меняет.
и при изменениях потребуется гораздо меньше сил на рефакторинг
А пример есть, где такой реальный рефакторинг был, что пришлось потратить много сил переделывая из newarr в List?
Несколько коллег пытались полизать, но жаба оказывалась достаточно шустрой и ускользала. ;)
Плюс в Guava есть куча плюшек вроде ImmutableList, Iterables.concat, Iterables.filter, Lists.partition и много ещё чего, что на массивах не работает.
itertools из фитона? Хотет!
Благодаря ему можно будет через слои передавать не сам объект а ссылку на него и только в том месте где нам понадобятся данные, сохранить в память, то есть сделать ToList();
Не понял
> не обычный массив использовать а только IEnumerable
Элегантно придавая всем операциям сложность O(N)
А что ICollection умеет по сравнению с IEnumerable?
Если не получается IEnumerable, то лучше обычный, базовый, массив T[] (Array).
Передавай Ienumerable, что бы потом создать из него list.
>Элегантно придавая всем операциям сложность O(N)
Нет, вот операции проделывать с list, который мы получим из Ienumerable.
> Нет, вот операции проделывать с list, который мы получим из Ienumerable.
Превращение IEnumerable -> List уже O(N). Если бывает необходимость такой конверсии, почему же сразу не возвращать список?..
Вам придется из листа создать новый объект, и он останется. И так всегда, когда вам нужно будет работать с другим типом коллекций. Тогда зачем его сразу превращать.
> Элегантно придавая всем операциям сложность O(N)
Если ты используешь IList<T>, то ты и так не знаешь какая сложность при этом получится. Если там за ширмой ArrayList<T> (aka List<T>), то вставка\удаление в середину O(n), в то время как индексирование O(1), а если LinkedList<T>, то ситуация совершенно обратная. Да и вообще зачем выделять целых 100500 элементов, если тебе понадобиться лишь первые 3 записи. Ситуация ещё хуже, если ты вернул List<T>, а результат нужен только для чтения, а ты ради производительности не сделал копию (что конечно же глупо, особенно в условиях существования ReadOnlyCollection<T>). Так что тут в любом случае рекомендация делать наиболее обобщенно, а именно IEnumerable<T>. Он и менять не позволяет. Он и лишних элементов не считает. Воспользуешься .Take(3), а там уж передашь в конструктор ArrayList<T> или LinkedList<T> в зависимости от того - какие операции тебе будут чаще нужны. На уровне DataLayer вопросы наиболее часто используемых операций в клиентском коде не решаются, поэтому только IEnumerable<T>, если можешь. Вот снизу подсказывают про файл. В Шарпике для закрытия энумерабельных файлов есть using. PS Борманду: Не то что в каком то там Хаскеле.
>Элегантно придавая всем операциям сложность O(N)
Если не использовать обращение по индексу, то она и так будет O(N).
А в шарпике же как и в жабе - все объекты и массивы и так передаются по ссылке. И только примитивы и структуры по значению..
Или вы имеете в виду ленивость? Т.е. то, что список будет строиться только тогда, когда сделают ToList или побегут по енумерейблу. Ну это далекооо не всегда можно применить... Тот же курсор от базы или файл часто нужно закрыть почти сразу после запроса/чтения, а тогда никакой ленивости не получится - нужно читать все что нужно и закрывать.
1. Entity Framework, LINQ, ASP.NET MVC.
2. Использование Array вместо List<T> в целях улучшения производительности.
Как-то совсем уж странно. Что-то тут не так.
К стати, провёл несколько тестов, код:
http://govnokod.ru/13301
получается быстрее копирования по свойствам через рефлексию, если массивы получаются больших размеров.
http://govnokod.ru/13426#comment188414
http://govnokod.ru/13426#comment188415
Речь может идти исключительно о производительности, непосредственной или опосредованной.
Что касается клонирования. Приведите код, очень стало интересно. По каким причинам у Вас отражение + работа с потоком байт оказалось быстрее просто отражения. Здесь явно что-то не так.
Что касается того поста. Понимаете, нет такого вопроса, что быстрее, клонирование сериализацией, клонирование через отражение или какой-то другой экзотический способ. Есть вопрос, что меньше нагрузит наш сервер. И есть факт: написание кода клонирования многократно быстрее любого другого способа клонирования. Когда нужно клонировать 500 объектов, каждый из которых в процессе клонирования сериализацией выдаёт поток в 50Кб, серьёзно нагружает систему и исполняется слишком долго, чтобы это можно было делать несколько раз в секунду, сам факт, что это работает быстрее отражения, ничего не значит. Если нужно, чтобы такая операция вообще никак не отражалась на состоянии сервера, нет никаких других вариантов.
needle более правильно сформулировал мою мысль:
http://govnokod.ru/13426#comment188515
Приведите код, очень стало интересно. По каким причинам у Вас отражение + работа с потоком байт оказалось быстрее просто отражения. Здесь явно что-то не так.
Да, я реально что-то напутал...
http://ideone.com/XF1c2u
Результат с прекомпилированном варианте (без mono) (+-2sec.):
Measure с rsdn'а.
Жава-жва, не смеши меня так.
Но при этом, моя приверженность к RAD, сполна окупает негатив от такой производительности.
Собственно, тенденция с List<T> просто очередной этап забивания.
Так что недалеки те дни, что код:
http://govnokod.ru/7004
Будет абсолютно нормальным.
1. IEnumerable никак не поможет, если вдруг придётся изменить список на словарь. Использование IEnumerable может быть оправдано, но не ссылками на то, что вдруг может возникнуть необходимость что-то сделать с коллекцией.
2. Использование таких вещей, как LINQ и Entity Framework, а также ninject и ASP.NET MVC не очень хорошо согласуются с рассуждениями о том, что некая коллекция из нескольких элементов при копировании фактически указателей будет обладать сложностью O(n). Это немного странно.
У нас есть метод в BL, который отдаёт заранее определённый массив данных:
Почему отдавть его в виде IEnumerable или T[] хуже, чем отдать его в виде List<T>?
Зачем предугадывать поведение клиента и отдавать заранее подготовленный массив в виде List<T>?
Не понятно, где тут появляется Dictionary и возможность заменить List на Dictionary.
В примере
http://govnokod.ru/13426#comment188640
вы использовали List<T> не по назначению.
Понятное дело, можно свалить на "вот такой дизайн" и "написали и забыли". Но это был не более чем аналогичный тестовый пример.
Не понятно, где тут появляется Dictionary и возможность заменить List на Dictionary.
Если я правильно понял нашего коллегу, то Dictionary было взято в качестве примера Т.е.:
1) Чем проще базовый тип, тем проще с ним орудовать.
2) Гадать за клиента что за функционал ему понадобиться - бессмысленно.
List<T> будет работать значительно быстрее, если в конструктор List<T>, в строках 53 и 73, Вы сразу передадите capacity (_childCount). В таком случае не произойдёт копирования массива после 4го элемента (См. http://govnokod.ru/13426#comment188459)
Если пойти ещё дальше, то свойство Children инициализируется в 2х местах (53,73), хотя можно всю инициализацию осуществить в рекурсионном методе CreateChildren(...).
Мне известно о чудотворном свойстве конструктора, передающего капасити. Но в данном случае меня не интересует производительность кода, который создаёт тестовые данные. Во-первых, мы замеряет производительность не этого кода, во-вторых, этот код не имеет значения в данном примере. Ваш пример с массивом простейших данных показался мне неубедительным. Чаще всего нет нужды клонировать такой массив, но есть необходимость в клонировании дерева, которое очень часто состоит из множества объектов нескольких определённых типов.
Свойство Children инициализируется один раз для каждого объекта. В данном случае мне важна была простота написания лично для меня и понимания для других.
Словом, этот код мне ни разу не дорог, я нисколько не против того, если Вы напишете так, как считаете нужным.
Он там лишний. Функционал List'а во View никаким чудодейственым образом использоваться не будет и не должен.
Если, вдруг, он туда попал, то это прокол проектировщика Model'а.
Т.е. каждый объект должен использоваться к месту. Иначе и вправду близки те дни, что можно будет всё через String передавать...
Мне, тем не менее, стало интересно, какие задачи Вам приходится решать. И не могли бы Вы оценить в любых удобных терминах и единицах измерения наиболее существенную проблему, которую Вам доводилось решать?
На текущем, недавно внедрил AppFabric на ферму серверов, т.к. они создавали приличную нагрузку на сервера данных при обновлении кешей. В будущем, как запустим очередную ветку развития бизнеса, планирую на одно решение внедрить CEP в виде StreamInsight.
До этого АСУ ТП занимался, но это уже больше к алгоритмам и к плюсам.
Вообщем, пока самый большой фейл с BizTalk'ом был... Надеюсь, на вопрос ответил.
http://govnokod.ru/13426#comment188738
Какой гибкости?
Не подразумевает по собой конструктивного общения?
Перефразирую:
Подскажите, пожалуйста, какую гибкость Вы подразумевали в своём примере использования List<T>, которую я упустил устроив такой рефакторинг?
Если Вы зададитесь вопросом о том, почему Вы использовали именно такую форму речи, то ответ вряд ли будет вразумительнее ответа Вашего коллеги.
А как бы Вы задали подобный вопрос, если-бы коллега всё отдавал List'ами без разбора?
Ну и заодно, как-бы Вы на него ответили, если такой вопрос адресовали бы Вам?
Как бы я задал вопрос? Я бы задал такой вопрос на проекте, в котором очень жёсткие требования ко всему. И скорее всего, зарезал бы на собеседовании. А когда проекты мелкие и длятся 2-4 месяца, по итогам эти проекты работают и всех всё удовлетворяет, я бы не стал уделять большого внимания таким мелочам. Я бы решил эти проблемы в течение испытательного срока такого программиста. Если они не решены у вас, то почему? - вот главный вопрос, который нужно задать.
Есть фактор масштаба. Как правило, некультурный программист совершает более масштабные диверсии. Мне доводилось сокращать время процедуры с 65 часов до 54 минут, резко снижать требования к железу на сервере. Согласитесь, вот это - реальная проблема и подлинный говнокод. Соединения тред-статик - подлинный говнокод. Код, который невозможно читать - безусловно, тоже.
У программиста может быть свой опыт, и он может вполне добросовестно делать не вполне правильные вещи. У программиста может быть задача на человеко-год, которую от него требуют выполнить в два раза быстрее. А сделать надо хорошо.
Как бы ответил я. У меня всегда есть план работ и некая стратегия. Простой вопрос. Если есть иерархия на 120 классов на 6 уровнях, а всего под неё изменено 500 классов и создано 250 новых, и во всем этом возник мелкий технический долг, что перевешивает:
а) наличие ценного и правильно написанного функционала, улучшившего параметры в 10 раз,
б) или мелкая проблема, которую очень просто исправить?
Технический же долг я оформляю в виде задач, которые выполняю, когда возникает возможность. Если мне указывают на мои явные ошибки, я их исправляю. А вообще я трепетно отношусь к тому, что называется производительность в мелочах.
IEnumerable - база. В некоторых случаях, использование базы намного эффективней Array'я.
1) Ленивая инициализация данных.
Для примера:
http://msdn.microsoft.com/en-us/library/system.resources.resourcereader.aspx
Отдаёт уже инициализированный объект DictionaryEntry, если сборку, куда ссылается тип ресурса загрузить не удалось, то будет исключение. Но исключение будет только на тех ресурсах, сборку которых не удалось загрузить, а не на всём массиве целиком.
2) Если из всего массива нужно будет всего n первых элементов. Или часть пропустить.
3) Код читает данные из "опасного источника", который на следующем элементе может уйти в исключение. (Идентично пп.1, толко на этом остановка чтения.)
4) У клиента есть возможность остановить входящий поток на полученных n элементах.
Соовтетственно, отдавая базу, Вы делаете код не только более гибким в плане архитектуры, но ещё и даёте клиенту право распоряжаться полученными данными самостоятельно, а не думать как из объекта верхнего уровня, перевести данные в другой объект верхнего уровня.
Я бы задал такой вопрос на проекте, в котором очень жёсткие требования ко всему.
На моей практике, лучше держать всех соратников в тонусе, тогда тот, кто не уверен в использовании чего-то, лучше подойдёт и лишний раз спросит, чем сначала сделает такой "финт ушами", как с тред-статиком.
Согласитесь, вот это - реальная проблема и подлинный говнокод.
В большинстве своём, такой говнокод в рамки сайта не поместится.
Если они не решены у вас, то почему?
У нас много отделов.
а) наличие ценного и правильно написанного функционала, улучшившего параметры в 10 раз,
б) или мелкая проблема, которую очень просто исправить?
Если а) подразумевает под собой "работает? - не трогай", то тогда лучше не трогать.
[Serializable]
public class DataItem
{
public Int32 Property1 { get; set; }
public String Property2 { get; set; }
public Int32 Property3 { get; set; }
public DataItem Parent;
public List<DataItem> Children;
}
Тут сразу возникает несколько проблем, которые выглядят уже не настолько безобидно.
http://ideone.com/Pplqja
http://govnokod.ru/13301#comment185987
Когда я изучал проблему с клонированием, то наткнулся ещё вот на такой вариант:
http://whizzodev.blogspot.ru/2008/06/object-deep-cloning-using-il-in-c_20.html
Но так и не дошли ручки его потестить.
Более того, когда мы хотим скопировать поддерево, автоматизация без дополнительных сущностей никак не поможет. А такие моменты встречаются. Например, нам нужно отправить 50 байт, а приходится отправлять мегабайт. И так могут делать сотни клиентов. Нехорошо получается.
http://govnokod.ru/13301#comment185987
я писал, что объекты разные.
Один SourceData[] inArray, а второй OutputData[] outArray и клонировать один объект в другой объект - не выйдет...
У одного:
у второго:
Оба класса автогенерируемые, даже смысла нет заморачиваться и поддерживать ISerializable.
Например, нам нужно отправить 50 байт, а приходится отправлять мегабайт.
Я рад что хоть кто-то ещё переживает за траффик. А то тенденции с пиханием в тонкий клиент мегатонны jQuery и Ко., меня удручает...
На самом деле, с gzip и кешированием - всем похуй. Меня больше удручает долгая загрузка страницы, а если еще и синхронная подгрузка и скрипт не качается - страница виснет на это время.
На сайте сонистайл.ком, до взлома сети сони, в HTML вёрстке можно было историю изменения обнаружить с датами и авторами...
Да, косяк там, т.к. писал прям тут. В конце не хватает: return result;
- Зачем тебе он везде?
Ответ меня очень удивил:
- А вдруг понадобится.
Надеюсь, в Вашем случае это не ответ.
Очень крутая смесь технологий и при правильном построении архитектуры, можно быстро создать практически пол функционала приложения. Для этого можно еще добавить ninject и юнит-тесты.
И да, я сначала получаю IEnumerable или ICollection, но в основном не из-за производительности, а для возможности создавать другие коллекции, которые реализуют этот интерфейс.