为什么Java集合不提供方便的映射方法？

Question

我想知道为什么Java Collections API不包含map不同集合类型的方便方法.我想写一些类似的东西:

List<Foo> list = ...;    
List<String> result = list.map(Foo::toString);

相反,我必须创建一个流,地图和收集,如下所示:

List<Foo> list = ...; 
List<String> result = list.stream().map(Foo::toString).collect(toList());

难道不像在java.util.List接口中实现这个默认方法那么容易吗？例如

default <R> List<R> map(Function<E, R> mapper){
    return stream().map(mapper).collect(Collectors.toList());
}

乍一看,似乎有其他方便的方法.例如:

list.stream().forEach(x -> {});

可写成

list.forEach(x -> {});

但是,比较并不是那么好.Iteratable.forEach是顶级接口上的默认方法,不需要指定返回类型.它不是在引擎盖下创建一个流,而是使用Iteratables属性来......好......迭代所有元素.

所以问题仍然存在:为什么不在每个Collections API接口上都有map方法？也许是因为它不够灵活,因为你需要决定一个返回类型？

我确信实现者已经考虑过它,并且有理由不把它放进去.我想了解原因.

Answer 1

是的,这是故意的.我听过的一些原因讨论过:

• 很多时候,这些方法被链接在一起,在这种情况下,仅在计算结束时收集到显式数据结构中更有效
• 控制界面的绝对大小; 管理自动填充中出现的选项数量
• 避免与Collection已提供的已提供方法的外部实现冲突map,等等.
• 使用专门的配置方法将所有流畅的功能构建到一个连贯的API中parallel(); 而且,API现在可以与其构建的集合分开进化
• 正如你所提到的,让用户明确决定返回类型的实现 - 如果你有一个任意的Collection并且被调用map,它可以是a List,还是一个Set静默地重复删除它的输出？!那会非常混乱