从我读到的最佳实践到"总是"公开你的类的接口。
因此,假设呼叫者无需接收Dictionary<string, string>
,我是否应该返回IEnumerable<KeyValuePair<string, string>>
,即使我的班级内部使用Dictionary<string, string>
?
我的代码如下:
public static IEnumerable<KeyValuePair<string,long>> GetHddSize()
{
var drives = DriveInfo.GetDrives();
var dictionary = drives.ToDictionary(drive => drive.Name, drive => drive.TotalSize);
return dictionary;
}
答案 0 :(得分:2)
Dictionary<string, string>
不只是IEnumerable<KeyValuePair<string, string>>
。
在某些情况下,如果您返回IEnumerable(大多数情况下,当您想要枚举一个集合时),您根本不在乎,但是当您想要从外部添加项目时会发生什么?字典限制的多个键和IEnumerable没有?
您在代码中使用词典的原因。
答案 1 :(得分:1)
取决于调用者打算使用的方法。 IEnumerable<KeyValuePair<string,long>>
看起来很难看。如果您想返回界面,我建议您返回IDictionary<string,long>
。
答案 2 :(得分:1)
根据你的说法,你仍然不知道如何使用这种方法的返回值。这种情况一直发生在编码时 在这种情况下,我想在另一个类中包装数据(在本例中为字典)。引入一个新类给了我很大的灵活性:我可以稍后更改它,扩展它或强制访问策略。如果有一天我意识到我不需要它,我可以重构并删除该课程。
答案 3 :(得分:0)
你可以,但不要。它为我们提供了灵活性,尤其是收藏品。如果您不使用其他类型的数据结构,例如Container,您可能不会需要使用它。
我的意思是,如果您使用不同的结构但使用相同的模板,例如List或Queue,您可以像使用的那样使用。例如,您可以在相同的代码部分中迭代List和Queue。
我希望得到回答。
答案 4 :(得分:0)
我认为IDictionary是一个很好的选择,因为@Amir给出的原因,以及枚举不提供的字典的随机访问选项。但是如果你想用本土的东西替换它,我不会公开字典。例如,Dictionary不可序列化。 IDictionary的界面相对较小,如果有必要用其他内容替换你的内部数据持有者,可以重新实现。