IEnumerable <T>null объединяющее расширение - PullRequest
Новая
       91

IEnumerable <T>null объединяющее расширение

5 голосов
/ 12 апреля 2011

Я часто сталкиваюсь с проблемой, чтобы проверить, является ли IEnumerable<T> нулевым, прежде чем итерировать его через запросы foreach или LINQ, тогда я часто сталкиваюсь с такими кодами: 

var myProjection = (myList ?? Enumerable.Empty<T>()).Select(x => x.Foo)...

Следовательно, я подумал добавить этот метод расширения в класс Extensions: 

public static class MyExtensions 
{
    public static IEnumerable<T> AsEmptyIfNull<T>(this IEnumerable<T> source)
    {
        return source ?? Enumerable.Empty<T>();
    }
}

При взгляде на этот код сразу возникает небольшая проблема, т. Е. Учитывая "аспект-методы-аспекта" расширений-методов, он должен быть реализован как простой статический метод, в противном случае что-то вроде это было бы совершенно законно: 

IEnumerable<int> list = null;
list.AsEmptyIfNull();

Видите ли вы какой-либо другой недостаток в его использовании?
Может ли такое расширение привести к какой-то плохой тенденции в разработчике (ях), если широко используется?

Бонусный вопрос:

Можете ли вы предложить ему лучшее имя? :)
(Английский не мой родной язык, тогда я не так хорош в названии ...)

Заранее спасибо.

Ответы [ 2 ]

7 голосов
/ 12 апреля 2011

Методы, которые возвращают IEnumerable<T>, должны возвращать пустой, а не ноль. Так что тебе это не понадобится.

См. Этот вопрос: Лучше ли вернуть пустую или пустую коллекцию?

В противном случае ваш код выглядит нормально.

3 голосов
/ 12 апреля 2011

Обычно плохая идея - возвращать null вместо пустой последовательности, если вы можете ее контролировать.Это самоочевидно, если учесть, что когда кого-то просят создать коллекцию, возвращение null - это не то же самое, что сказать «коллекция пуста», но «такой коллекции нет вообще».

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

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

...