假设我想要松散耦合的接口,我经常避免在方法签名中使用 List 实现(如 ArrayList),而更喜欢使用 List 接口。但是由于 Collection 是一个更通用的接口,你认为我应该更喜欢使用 Collection 而不是 List 吗?
编辑:我知道列表和集合之间的区别。我不关心订单或任何特定于列表的功能。这个问题是关于返回值和方法参数的。
假设我想要松散耦合的接口,我经常避免在方法签名中使用 List 实现(如 ArrayList),而更喜欢使用 List 接口。但是由于 Collection 是一个更通用的接口,你认为我应该更喜欢使用 Collection 而不是 List 吗?
编辑:我知道列表和集合之间的区别。我不关心订单或任何特定于列表的功能。这个问题是关于返回值和方法参数的。
从 List 的文档(它扩展了 Collection):
有序集合(也称为序列)。此界面的用户可以精确控制每个元素在列表中的插入位置。用户可以通过整数索引(列表中的位置)访问元素,并在列表中搜索元素。
简而言之: List 保留其元素的顺序(插入顺序或您选择强加的任何其他顺序)。
因此,如果您关心这些事情中的任何一个,请使用 List。
一个好的 API 应该提供所有需要的东西,而不会暴露不必要的实现细节。
我发现自己最常使用 List 或 Set。尝试用 Collection 替换 List 或 Set 有时会使 API 难以使用,而没有真正提供任何额外的解耦或抽象。
我尽量避免在方法签名中使用 Maps,因为我认为这是输入/输出过于复杂的迹象。这可以通过为该数据创建一个特定的包装类或通过更改方法的位置以便它可以直接访问数据来解决(例如,将其放入您传递给该方法的类中)。
不要忘记您的面向对象设计是为了让那些维护和调用您的代码的人的生活更轻松,而不是为了达到完美的圣杯。通常有几种合理的方法可以对问题进行建模,您选择哪一种取决于您自己的风格以及您正在处理的代码库的预期未来复杂性/用例。
我只去List
,Set
或Map
。这给调用者一些指示,他们可以期望得到什么,而不是太具体。
我认为将该指示作为方法签名的一部分很重要。它可以改变他们计划使用结果的方式。
例如。Collection
不保证唯一的条目Set
。返回List
意味着结果将被排序,等等。
这取决于你打算做什么。
如果顺序不重要,Collection
可以说得过去List
。
一般来说,正如您所建议的,在方法参数中使用高级接口通常是一种很好的做法,这样调用代码确实需要进行任何转换以满足方法要求。
这取决于。该Collection
接口具有与List
. 当您迭代 a 的元素时,Collection
您不会期望元素以特定顺序返回。(确实对于某些集合类型,迭代顺序实际上是不可预测的。)
此外,您可以使用 API 执行许多使用List
API 无法执行的操作Collection
。例如在特定位置获取、插入或删除元素。