powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / WinForms, .Net Framework [игнор отключен] [закрыт для гостей] / Производительность - возвращенный интерфейс
25 сообщений из 58, страница 1 из 3
Производительность - возвращенный интерфейс
    #39628747
Фотография Gobzo Kobler
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я уже не помню как и откуда, но усвоил никогда не возвращать из метода интерфейс, а только конкретный тип. ЕМНИП если возвращать интерфейс, страдает производительность. Но тут попал в дурдом, где все методы возвращают интерфейсы. Типа
Код: c#
1.
public IEnumerable<string> GetItems()


против привычного
Код: c#
1.
public List<string> GetItems()


Помогите объяснить в конкретных терминах, чем это плохо. Нутром чую что это неправильно, но уже не помню откуда это взял.

Вариант где может вернуться разный класс не рассматриваются
Код: c#
1.
2.
3.
4.
5.
public IEnumerable<string> GetItems(bool something)
{
  if(something) return new List<string>{"a"};
  else return new ConcurrentBag<string>{"b"};
}


В этой конкретной ситуации метод возвращает только один тип.
...
Рейтинг: 0 / 0
Производительность - возвращенный интерфейс
    #39628750
Фотография Denis.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
если речь про скорость вызова метода через класс или интерфейс то этим можно пренебречь.
Есть такой принцип что нужно отдавать максимально специфичный тип и потреблять максимально общий. Я с ним не согласен и предпочитаю потреблять и отдавать максимально общий тип в контексте задачи, естественно. IEnumerable стоит особняком, с ним лучше аккуратнее так как он может быть реализован по разному и может получится что один и те же тяжелые вычисления(ну ил запросы куда то) делаются много раз + возможны ленивые вычисления. Я часто предпочитаю IReadonlyCollection, если в методе кроются вычисления. Иногда приходится тип делать более конкретным, но все равно предпочитаю оставлять его общим в рамках задачи. К примеру, если я знаю что возвращаю коллекцию по логике в которой нужно будет что то искать, я по ситуации могу вернуть, например, ISet<>
...
Рейтинг: 0 / 0
Производительность - возвращенный интерфейс
    #39628777
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gobzo Koblerпротив привычного
Код: c#
1.
public List<string> GetItems()



Никогда. Ещё раз. Никогда. Публичные методы. Не должны. Возвращать List !!!

Насчёт IEnumerable. Всё верно, если возвращать IEnumerable, производительность страдает. Но страдает не только производительность, это семантически не верно в большинстве случаев.

IEnumerable это БЕСКОНЕЧНОЕ перечисление по своей сути. Конечно, оптимизированные методы пытаются привести его к ICollection, чтобы прочитать количество элементов.

Основной свод правил такой:

Возвращаем (в порядке предпочтительности)

1. IReadOnlyCollection
2. IReadOnlyList
3. ICollection
4. IList
5. [] -- массив
5. IEnumerable (только в случаях, когда возвращаемый набор данных вычисляется лениво, например, с помощью LINQ или yield).

Но никогда нельзя возвращать List!

Принимам (в порядке предпочтительности)

1. IReadOnlyCollection
2. IReadOnlyList
3. IEnumerable (только в том случае, если принимающий метод проходит по списку один раз и заранее ему не требуется знать количество элементов)
4. ICollection
5. IList
6. [], params []

Нет, нельзя принимать List!

По поводу List. Его можно использовать только внутри реализации, можно принимать/отдавать только внутри приватных методов, даже не protected, только private.


Gobzo KoblerЯ уже не помню как и откуда, но усвоил никогда не возвращать из метода интерфейс, а только конкретный тип.

Я понятия не имею, откуда вам удалось «усвоить» этот бред. Но выкиньте его из головы. Если желаете работать на профессиональном уровне, в достойных командах, не делайте так. Всегда предпочитайте интерфейсы в публичных контрактах. Конечно без фанатизма, так как есть и обратный вариант тупизны, это везде бездумно использовать IEnumerable, это тоже не правильно, и как раз тут может пострадать и производительность и даже вовсе код может работать неправильно, так как IEnumerable это однопроходная коллекция, только для чтения. Никто не гарантирует, что при втором проходе вы получите тот же результат или вообще не словите ошибку.
...
Рейтинг: 0 / 0
Производительность - возвращенный интерфейс
    #39628778
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gobzo Koblerпротив привычного
Код: c#
1.
public List<string> GetItems()



Как же долго нам приходится выбивать вот эту дурь из головы джуниоров. Сколько копий сломано...

Ээээх...
...
Рейтинг: 0 / 0
Производительность - возвращенный интерфейс
    #39628779
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gobzo KoblerПомогите объяснить в конкретных терминах, чем это плохо.

Объясняю на пальцах. Возвращая List, вы по сути выставляете кишками наружу реализацию. Естественно, это будет не единичный случай, другие методы будут ожидать List. Ещё хуже это сказывается при использовании generics, например, для async/await. Просто физически будет крайне сложно провести хоть какой-то рефакторинг. Например, проксировать, декорировать коллекции будет тупо невозможно. Невозможно будет заменить List на более подходящую в данном конкретном случае коллекцию. А также с тестированием будут сложности и проблемы.

На каком-нибудь лабораторном примере из сотни строк кода, да, проблему здесь трудно увидеть. Но лучше изначально приучать себя кодить правильно, а не как джун.
...
Рейтинг: 0 / 0
Производительность - возвращенный интерфейс
    #39628793
Сон Веры Павловны
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttЕщё хуже это сказывается при использовании generics, например, для async/await.
И ко/контрвариантность работает только с интерфейсами, для классов будет облом.
...
Рейтинг: 0 / 0
Производительность - возвращенный интерфейс
    #39628794
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сон Веры ПавловныhVosttЕщё хуже это сказывается при использовании generics, например, для async/await.
И ко/контрвариантность работает только с интерфейсами, для классов будет облом.

Спасибо за дополнение :)
...
Рейтинг: 0 / 0
Производительность - возвращенный интерфейс
    #39628853
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ко/контравариантность в C# это реализация принципов Контрактного программирования (DbC).

Собственно, ковариантность - это _возвращение_ типа, производного от базового (который определен в интерфейсе C#) - это контракты на то, что возвращаемое значение/тип (посткондиция в терминах DbC) вызывающей ф-ции/производного класса должны оба удовлетворяться (в т.ч быть совместимыми по типам). Т.е возвращаемый тип должен ужесточать/сужать требования по типу и значениям!

Аналогично, контравариантность - это _получение_ типа, производного от базового. И является прекондицией - в этом случае в вызывающей функции/производном классе должно выполняться хоть один из контрактов(для шарпа это применяется в делегатах). Таким образом по иерархии классов в сторону наследников или субвызовов мы можем расширять принимаемые типы.

Так что тов.Хвост, с точки зрения абстрактной теории, таки прав на 50%. На практике же все не так однозначно.

Конечно, придется рефакторить при смене иерархий, но зато мы исключаем(снижаем) вероятность такого замечательного Иксепшна "Ой, а что это за неизвестный тип мне прилетел, я не умею!"


Ну а с точки зрения производительности .vs. C# + интерфейсы это уже совсем попендикулярная история.
...
Рейтинг: 0 / 0
Производительность - возвращенный интерфейс
    #39628876
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttGobzo KoblerПомогите объяснить в конкретных терминах, чем это плохо.

Объясняю на пальцах. Возвращая List, вы по сути выставляете кишками наружу реализацию. Естественно, это будет не единичный случай, другие методы будут ожидать List. Ещё хуже это сказывается при использовании generics, например, для async/await. Просто физически будет крайне сложно провести хоть какой-то рефакторинг. Например, проксировать, декорировать коллекции будет тупо невозможно. Невозможно будет заменить List на более подходящую в данном конкретном случае коллекцию. А также с тестированием будут сложности и проблемы.

На каком-нибудь лабораторном примере из сотни строк кода, да, проблему здесь трудно увидеть. Но лучше изначально приучать себя кодить правильно, а не как джун.Ну давай класс String тоже за интерфейсом скроем... А то мало ли чего... Простите, не удержался...
...
Рейтинг: 0 / 0
Производительность - возвращенный интерфейс
    #39628889
Сон Веры Павловны
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей КНу давай класс String тоже за интерфейсом скроем... А то мало ли чего... Простите, не удержался...
Толку его скрывать за интерфейсом, если он иммутабельный. Вот StringBuilder - ага, можно.
...
Рейтинг: 0 / 0
Производительность - возвращенный интерфейс
    #39628893
Сон Веры Павловны
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Siemarglно зато мы исключаем(снижаем) вероятность такого замечательного Иксепшна "Ой, а что это за неизвестный тип мне прилетел, я не умею!"
Возможность ко/контрвариации контролируются на этапе компиляции. О каком эксепшене речь?
...
Рейтинг: 0 / 0
Производительность - возвращенный интерфейс
    #39628896
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglТак что тов.Хвост, с точки зрения абстрактной теории, таки прав на 50%. На практике же все не так однозначно.

У нас кодовая база на 100% этому следует. На практике, приходят джуны и начинают городить List<T>.
Вот и всё.


SiemarglКонечно, придется рефакторить при смене иерархий, но зато мы исключаем(снижаем) вероятность такого замечательного Иксепшна "Ой, а что это за неизвестный тип мне прилетел, я не умею!"

Вот здесь не понял.
...
Рейтинг: 0 / 0
Производительность - возвращенный интерфейс
    #39628897
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей КНу давай класс String тоже за интерфейсом скроем... А то мало ли чего... Простите, не удержался...

Да ты... да понятно уже всё с тобой
...
Рейтинг: 0 / 0
Производительность - возвращенный интерфейс
    #39628900
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сон Веры ПавловныВот StringBuilder - ага, можно.

StringWriter
...
Рейтинг: 0 / 0
Производительность - возвращенный интерфейс
    #39628960
Roman Mejtes
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt,

нельзя так категорично, в разных ситуациях используют разную логику.
возьмём к примеру ItemsControl
Код: c#
1.
public ItemCollection Items


пожалуйста, никаких интерфейсов и свойство Public.
Вариантов таких много.

Меня больше раздражает то, что интерфейсы очень часто используют там, где они нафиг не нужны.
...
Рейтинг: 0 / 0
Производительность - возвращенный интерфейс
    #39628994
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сон Веры ПавловныАлексей КНу давай класс String тоже за интерфейсом скроем... А то мало ли чего... Простите, не удержался...
Толку его скрывать за интерфейсом, если он иммутабельный. Вот StringBuilder - ага, можно.Ну и что, что иммутабельный... Надо возвращать IEnumerable<char> . А то вдруг чего!
...
Рейтинг: 0 / 0
Производительность - возвращенный интерфейс
    #39629116
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Roman Mejtesнельзя так категорично, в разных ситуациях используют разную логику.
возьмём к примеру ItemsControl
Код: c#
1.
public ItemCollection Items



пожалуйста, никаких интерфейсов и свойство Public.
Вариантов таких много.

ItemCollection, это изначально публичный контракт. Но даже такого в фреймворке уже с недавних пор все меньше и меньше.


Roman MejtesМеня больше раздражает то, что интерфейсы очень часто используют там, где они нафиг не нужны.

Например?
...
Рейтинг: 0 / 0
Производительность - возвращенный интерфейс
    #39629118
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей КНу и что, что иммутабельный... Надо возвращать IEnumerable<char> . А то вдруг чего!

Чего сказать-то хотел? )
...
Рейтинг: 0 / 0
Производительность - возвращенный интерфейс
    #39629127
eny
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
eny
Гость
hVosttGobzo KoblerПомогите объяснить в конкретных терминах, чем это плохо.

Объясняю на пальцах. Возвращая List, вы по сути выставляете кишками наружу реализацию. Естественно, это будет не единичный случай, другие методы будут ожидать List. Ещё хуже это сказывается при использовании generics, например, для async/await. Просто физически будет крайне сложно провести хоть какой-то рефакторинг. Например, проксировать, декорировать коллекции будет тупо невозможно. Невозможно будет заменить List на более подходящую в данном конкретном случае коллекцию. А также с тестированием будут сложности и проблемы.

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

Полностью поддерживаю!!!
Плюс еще одна тонкость - затраты времени на выделение и запись в памяти.
List или Array это статические объекты, в которые нужно выделить и в них аккуратненько сложить данные. А потом, чаще всего, по ним просто так "быстро пробегают" итератором. Да пробежать сферический, уже подготовленный, список - быстрее по индексу.
Но если данные изначально должнны быть откуда-то (с помощью LINQ хе-хе) найдены, а потом запихнуть их в список - прощай производительность и быстродействие, а потом рассказывают байки что LINQ тормозной и память жрет. Лучше вообще не использовать всякие там ToList и ToArray ;) начинающими.
Так что, если вы знаете что LINQ запрос вернет миллион значений, нужно очень сильная необходимость для складывания этого дела в список, лучше уж вернуть IEnumerable наверх для дальнейших действий.
...
Рейтинг: 0 / 0
Производительность - возвращенный интерфейс
    #39629255
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
eny,
Вопрос был не про linq, а про то в чем возвращать список из 10 строк.
Справочник валют какой нибудь.
...
Рейтинг: 0 / 0
Производительность - возвращенный интерфейс
    #39629256
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttАлексей КНу и что, что иммутабельный... Надо возвращать IEnumerable<char> . А то вдруг чего!

Чего сказать-то хотел? )
Ну юмор у него на 5 баллов))).
...
Рейтинг: 0 / 0
Производительность - возвращенный интерфейс
    #39629258
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Roman MejtesМеня больше раздражает то, что интерфейсы очень часто используют там, где они нафиг не нужны.+1
...
Рейтинг: 0 / 0
Производительность - возвращенный интерфейс
    #39629321
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123Roman MejtesМеня больше раздражает то, что интерфейсы очень часто используют там, где они нафиг не нужны.+1

Так можно сказать про что угодно. Единственный момент, что можно исправить, это перестать раздражаться ))
...
Рейтинг: 0 / 0
Производительность - возвращенный интерфейс
    #39629356
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сон Веры ПавловныSiemarglно зато мы исключаем(снижаем) вероятность такого замечательного Иксепшна "Ой, а что это за неизвестный тип мне прилетел, я не умею!"
Возможность ко/контрвариации контролируются на этапе компиляции. О каком эксепшене речь?Когда ты получил максимально общий (базовый) тип на возврате - часто придется приводить тип к нужному потомку.
...
Рейтинг: 0 / 0
Производительность - возвращенный интерфейс
    #39629359
eny
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
eny
Гость
Petro123eny,
Вопрос был не про linq, а про то в чем возвращать список из 10 строк.
Справочник валют какой нибудь.

Тогда вообще никакой разницы в быстродействии, но использование IEnumerable предпочтительней, ибо дает определенную гибкость и архитектурные плюшки.
...
Рейтинг: 0 / 0
25 сообщений из 58, страница 1 из 3
Форумы / WinForms, .Net Framework [игнор отключен] [закрыт для гостей] / Производительность - возвращенный интерфейс
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]