IEnumerable空合并扩展
我经常遇到这样的问题：在通过 foreach 或 LINQ 查询迭代 IEnumerable 之前检查它是否为空，然后我经常遇到这样的代码：
var myProjection = (myList ?? Enumerable.Empty<T>()).Select(x => x.Foo)...
因此，我想添加这个扩展 -扩展类的方法：
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();
您认为使用它有任何其他缺点吗？
如果大量使用，这样的扩展是否会导致开发人员出现某种不良趋势？
额外问题：
你能为它建议一个更好的名字吗？ <代码>:)
（英语不是我的母语，所以我不太擅长命名......）
提前致谢。
I frequently face the problem to check whether an IEnumerable<T> is null before iterating over it through foreach or LINQ queries, then I often come into codes like this:
var myProjection = (myList ?? Enumerable.Empty<T>()).Select(x => x.Foo)...
Hence, I thought to add this extension-method to an Extensions class:
public static class MyExtensions
{
public static IEnumerable<T> AsEmptyIfNull<T>(this IEnumerable<T> source)
{
return source ?? Enumerable.Empty<T>();
}
}
A little issue comes immediately in my mind looking at this code, i.e., given the "instance-methods aspect" of extension-methods, it should be implemented as a mere static method, otherwise something like this would be perfectly legal:
IEnumerable<int> list = null;
list.AsEmptyIfNull();
Do you see any other drawback in using it ?
Can such extension leading to some kind of bad-trend in the developer(s), if massively used?
Bonus question:
Can you suggest a better name to it ? :)
(English is not my first language, then I'm not so good in naming...)
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
返回
IEnumerable的方法应返回空值，而不是 null。所以你不需要这个。请参阅此问题： 返回 null 或空集合更好吗？
否则，你的代码看起来没问题。
Methods that return an
IEnumerable<T>should return an empty one, instead of null. So you wouldn't need this.See this question : Is it better to return null or empty collection?
Otherwise, your code seems ok.
如果可以控制的话，返回 null 而不是空序列通常是个坏主意。如果您认为当有人被要求生成一个集合时，返回 null 并不像说“集合是空的”而是“根本不存在这样的集合”，那么这是不言自明的。
如果您拥有返回枚举的方法，那么返回一个空的 IEnumerable（如果可能返回很多，它甚至可以是一个特殊用途的只读静态对象）是正确的方法。
如果您被迫使用一个习惯于在这种情况下返回 null 的不良库，那么这个扩展方法可能是一个解决方案，但我同样不喜欢它。最好将不礼貌的方法包装在您自己的版本中，以便在人们看不到的地方进行合并。通过这种方式，您既可以获得始终使用可枚举而不是 null 的便利性，又可以获得不支持“返回 null”范例的正确性。
It's generally a bad idea to return a
nullinstead of an empty sequence if you can control it. This is self-explanatory if you consider that when someone is asked to produce a collection, returningnullis not like saying "the collection is empty" but "there is no such collection at all".If you own the methods returning the enumerables, then returning an empty
IEnumerable(which can even be a special purpose readonly static object if it might be returned a lot) is the way to go, period.If you are forced to use a bad-mannered library that has the habit of returning
nullin such cases, then this an extension method might be a solution, but again I wouldn't prefer it. It's probably better to wrap the bad-mannered methods in your own versions that do the coalescing where people won't see it. This way you get both the convenience of always having an enumerable instead ofnulland the correctness of not supporting the "return null" paradigm.