java – 为什么Stream操作与收集器重复?
请允许我提出一些投诉,也许这很有意思,但我想描述:“为什么会提出这个问题?”.
我已经回答的问题与其他人不同,昨晚 here,here和 here. 在我深入研究之后,我发现在Stream和Collector之间存在许多违反Don’t repeat yourself原则的重复逻辑,例如:Stream#map& Collectors#mapping,Stream#filter& Collectors#filtering在jdk-9和.etc. 但自Stream起遵守Tell,Don’t ask原则/ Law of Demeter和Collector遵守Composition over Inheritance原则似乎是合理的. 我只能想到为什么Stream操作与Collector重复的原因如下: >我们不关心如何在大环境中创建Stream.在这种情况下,Stream操作比Collector更有效和更快,因为它可以简单地将Stream映射到另一个Stream,例如: consuming(stream.map(...)); consuming(stream.collect(mapping(...,toList())).stream()); void consuming(Stream<?> stream){...} > Collector功能更强大,可以将Collector组合在一起收集流中的元素,但是,Stream仅提供一些有用/高度使用的操作.例如: stream.collect(groupingBy( ...,mapping( ...,collectingAndThen(reducing(...),...) ) )); > Stream操作比Collector更加富有表现力,但它们比Collector更慢,因为它将为每个操作创建一个新流,而Stream比Collector更重,更抽象,例如: stream.map(...).collect(collector); stream.collect(mapping(...,collector)); > Collector不能将短路终端操作应用为Stream.例如: stream.filter(...).findFirst(); 是否有人能够提出其他不利/优势,为什么Stream操作与收集器重复?我想重新理解它们.提前致谢. 解决方法
链接专用终端流操作可能被认为更具表现力的是那些用于链接方法调用而不是组合收集器工厂调用的“LISP样式”.但它也允许流实现的优化执行策略,因为它知道实际操作而不是仅仅看到收集器抽象.
另一方面,正如您自己命名的那样,可以组合收集器,允许在不再可能进行流操作的地方执行嵌入在另一个收集器中的这些操作.我想,这种镜像只在Java 8开发的后期才变得明显,这就是为什么有些操作缺少对应的原因,比如filter或flatMapping,它们只存在于Java 9中.所以,有两个不同的API在做类似的事情,不是在开发开始时做出的设计决定. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |