IEnumerable <T>是否隐含了订单相关性,还是应该是明确的？

Question

对我来说,IEnumerable<T>在C#(嗯,.NET)中表示可以迭代的任意数据集.它可以由任何东西支持,例如SELECT查询结果,数组内容,用户在控制台中键入的字符或Pi的数字.索引不能引用数据,它不一定是有限的或无限的,也不能被修改.它甚至可以是稍后同样调用的不同数据集,就像IEnumerable<double>随机数一样.这只是一个像foreach循环一样产生给消费者的数据.

现在考虑一个处理数据集的其他概念:SQL.在SQL中,除非明确指定,否则行的顺序不保证且不相关.例如,如果你这样做SELECT * FROM stack_overflow_posts LIMIT 1,数据库没有暗示你得到的行实际上是插入的第一行,也不是最旧的行.例如,您需要明确地对结果进行排序ORDER BY posted_date_time.

这个相同的概念是否适用于.NET中的枚举IEnumerable<T>？是否使用了IEnumerable<T>一个含义,结果将始终按特定顺序产生？在我之前给出的例子中,我会说是的,订单会被暗示,因为如果它们以不同的顺序列举,结果将毫无意义; 如果您在控制台中以不同于实际击键的顺序获得用户键入的字符,那么阅读它们的重点是什么？显然,LINQ必须OrderBy()按顺序排序结果,但这是显式排序,而非隐含.

实现接口的类实际上有希望遵循特定模式,而不仅仅是实现接口定义的方法.是否IEnumerable<T>暗示其数据将以相关的顺序产生,或者如果他们希望这样做,是否由明确订购的消费者决定？如果我有一个方法以一个未定义的顺序产生项目 - 或者更确切地说,一个与消费者无关并且随时可能发生变化的订单 - 我应该使用除了以外的其他东西IEnumerable<T>吗？

Answer 1

是否使用了IEnumerable<T>一个含义,结果将始终按特定顺序产生？

不,IEnumerable只是保证对象可以迭代.List<T>例如,总是根据索引按升序输出项目的事实是List<T>具体的实现细节.

实现接口的类实际上有希望遵循特定模式,而不仅仅是实现接口定义的方法.是否IEnumerable<T>暗示其数据将以相关的顺序产生,或者如果他们希望这样做,是否由明确订购的消费者决定？

不,实施IEnumerable并不意味着任何订单.当使用对象时,IEnumerable如果要保证每次都以相同的顺序出现数据,则必须明确提供订单.

如果您考虑实现的CLR集合类型IEnumerable,这很简单.想象一下,您创建了一个返回的方法IEnumerable<string>.该方法可以返回一个List<string>,其实现IEnumerable 确实具有一定的顺序,但它可以很容易地返回一个HashSet<string>,对于这个顺序没有意义.

如果我有一个方法以一个未定义的顺序产生项目 - 或者更确切地说,一个与消费者无关并且随时可能发生变化的订单 - 我应该使用除了以外的其他东西IEnumerable<T>吗？

我会说这很IEnumerable<T>适合你的需求.为了更加清楚,您可以记录您的方法并声明结果中的项目顺序是未定义的,并且可能会在调用之间发生变化.

Answer 2

IEnumerable<T>不保证订单,但实施者或返回方法IEnumerable<T> 可以保证订单.例如,File.ReadLines保证按顺序为您提供文件行.Enumerable.Where保证保持秩序.但是,正如您所提到的,您可以轻松编写一个每次都产生新GUID的方法,并且它没有顺序.