13:28 добавил метод, нужный для вызова одной строки, якобы можно догадаться, что так будет соблюден SRP. 14:40 "Все круто". 11 строка избыточное отрицание в условии. 33 и 38 нарушение DRY, если не создавать избыточный метод. 22 используется конкретный класс вместо интерфейса, также название не соответствует содержанию, а соответствовало бы userNames.
имхо слабоватенько вышло: Проверка списка на нул, проверьте еще на пустой массив? вынести валидацию в отд приватный статик метод. тк CPU bound можно попробовать парралельно запустить Paraller.ForEach например.
@@DotNetInterviewPreparation С foreach-ем кстати непонятная ситуация. Почему-то его называют более медленным циклом, но мои замеры показывают, что в режиме релиза в студии он обгоняет for. Поэтому до сих пор не знаю, какой из циклов эффективнее.
@@DotNetInterviewPreparation сожалею, уже нет, т.к. делал в рамках эксперимента и в специально предназначенном для экспериментов (в широком смысле) проекте. Но это примитивный код, который не сложно воспроизвести - перечисление обычной коллекции (массива) двумя разными циклами, с вызовом сборщика мусора перед каждым замером, запуском таймера и выводом измеренного времени на консоль. Foreach чуть медленнее for если запускать проект в режиме дебага, и чуть быстрее, если в режиме релиза.
13:28 добавил метод, нужный для вызова одной строки, якобы можно догадаться, что так будет соблюден SRP.
14:40 "Все круто".
11 строка избыточное отрицание в условии.
33 и 38 нарушение DRY, если не создавать избыточный метод.
22 используется конкретный класс вместо интерфейса, также название не соответствует содержанию, а соответствовало бы userNames.
Вау, отличное дополнение к тому, что может быть улучшено! 👍👍👍
добавим немного абсурда )
public static void ProcessEntities(this IEnumerable source, Predicate predicate, Action? trueAction, Action? falseAction)
{
if (source == null) throw new ArgumentNullException(nameof(source));
if (predicate == null) throw new ArgumentNullException(nameof(predicate));
Parallel.ForEach(source,
entity =>
{
if (predicate(entity))
trueAction?.Invoke(entity);
else
falseAction?.Invoke(entity);
});
}
users.ProcessEntities(string.IsNullOrEmpty,
_ => Console.WriteLine("Invalid user"),
entity => Console.WriteLine($"{entity} processed"));
Отличный функциональный подход! Не скажу, что хотел бы такой видеть на работе, но мне нравится 😃👍
имхо слабоватенько вышло: Проверка списка на нул, проверьте еще на пустой массив? вынести валидацию в отд приватный статик метод. тк CPU bound можно попробовать парралельно запустить Paraller.ForEach например.
Отличное дополнение, спасибо 👍
тернарный оператор можно было бы добавить
Как вариант, да 👍
вроде как for по памяти меньше берет, а не foreach
Отличное замечание, да, можно было сделать чуть лучше по производительности с for-ом 👍
@@DotNetInterviewPreparation С foreach-ем кстати непонятная ситуация. Почему-то его называют более медленным циклом, но мои замеры показывают, что в режиме релиза в студии он обгоняет for. Поэтому до сих пор не знаю, какой из циклов эффективнее.
@@JamesBond-bu8co а можете кодом поделиться, которым замеряли?
@@DotNetInterviewPreparation сожалею, уже нет, т.к. делал в рамках эксперимента и в специально предназначенном для экспериментов (в широком смысле) проекте. Но это примитивный код, который не сложно воспроизвести - перечисление обычной коллекции (массива) двумя разными циклами, с вызовом сборщика мусора перед каждым замером, запуском таймера и выводом измеренного времени на консоль. Foreach чуть медленнее for если запускать проект в режиме дебага, и чуть быстрее, если в режиме релиза.