好吧,我希望整个社区能帮助我们解决一场已经持续了一段时间的职场辩论。这与定义接受或返回某种类型列表的接口有关。有几种方法可以做到这一点:
public interface Foo
{
Bar[] Bars { get; }
IEnumerable<Bar> Bars { get; }
ICollection<Bar> Bars { get; }
IList<Bar> Bars { get; }
}我自己的偏好是对参数使用IEnumerable,对返回值使用数组:
public interface Foo
{
void Do(IEnumerable<Bar> bars);
Bar[] Bars { get; }
}我支持这种方法的理由是,实现类可以直接从IEnumerable创建一个列表,然后使用List.ToArray()简单地返回它。然而,有些人认为应该返回IList而不是数组。我这里遇到的问题是,在返回之前,您需要再次使用ReadOnlyCollection复制它。对于客户端代码来说,返回IEnumerable的选项似乎很麻烦?
你使用/喜欢什么?(尤其是对于将由组织外部的其他开发人员使用的库)
发布于 2009-09-21 18:46:05
我的首选是IEnumerable<T>。任何其他建议的接口都会给出允许使用者修改底层集合的外观。这几乎肯定不是您想要做的,因为它允许消费者默默地修改内部集合。
另一个很好的例子是ReadOnlyCollection<T>。它允许所有有趣的.Count和索引器属性,并明确地告诉消费者“你不能修改我的数据”。
发布于 2009-09-21 18:46:19
我不返回数组-在创建应用程序接口时使用它们真的是一个糟糕的返回类型-如果您确实需要可变序列,请使用IList<T>或ICollection<T>接口,或者返回一个具体的Collection<T>。
另外,我建议你阅读Eric Lippert写的Arrays considered somewhat harmful:
前几天,我从一位编程语言教科书的作者那里得到了一个道德问题,询问我关于是否应该教初学者如何使用数组的意见。
我没有真正回答这个问题,而是给了他一长串我对数组的看法,我如何使用数组,我们期望未来如何使用数组,等等。这有点长,但是像Pascal一样,我没有时间把它变短。
让我从什么时候绝对不应该使用数组开始,然后对现代编程的未来和数组在未来世界中的角色进行更具哲学意义的讨论。
发布于 2009-09-21 18:49:54
对于已索引的属性集合(并且索引具有必要的语义含义),您应该使用ReadOnlyCollection<T> (只读)或IList<T> (读/写)。它是最灵活和最有表现力的。对于非索引集合,请使用IEnumerable<T> (只读)或ICollection<T> (读/写)。
方法参数应使用IEnumerable<T>,除非它们1)需要向集合添加/删除项(ICollection<T>)或2)需要用于必要语义目的的索引(IList<T>)。如果方法可以从索引可用性(例如排序例程)中受益,那么当实现失败时,它总是可以使用as IList<T>或.ToList()。
https://stackoverflow.com/questions/1456132
复制相似问题