使用只有一个项目的java Streams作为计算上下文--这是不是好的做法？
使用只有一个项目的java Streams作为计算上下文--这是不是好的做法？
提问于 2019-03-17 23:54:57
我经常问自己，创建一个项目的Stream是一种良好的做法，还是对其特性的一种利用。我们讨论的代码是这样的：
Stream.of(object)
.map(this::doSomething)
.map(this::doSomething)
.findAny();像Optionals一样，Streams使得在Java语言中实现更多的声明性代码成为可能，而不需要将指令绑定为函数并组成：
Function<x, y> doSomething = // some computation
Function<x, y> doSomethingElse = // other computation
doSomething.andThen(doSomethingElse).apply(object) // or using compose绑定中间变量的经典风格会产生如下代码：
var x = doSomething(object)
var y = doSomethingElse(x)虽然仍然是完全有效和可读的，但使用stream结构，我们可以自由地按顺序组合几个小函数-在我看来，这会导致更好的代码(很容易插入新的函数调用)。
我可以这样理解：
identity(Value.class)
.andThen(this::doSomething)
.andThen(something::execute)
.andThen(this::doSomethingElse)
.apply(value);但是我需要一个泛型方法，比如：
private <T> UnaryOperator<T> identity(Class<T> t) {
return UnaryOperator.identity();
}当然，我可以想出重用这些代码的方法，但我觉得应该有一种更好的、本机的方式来启动这个函数链。
Java或更好的方法可以启动这个函数合成链，而不需要将函数绑定到名称？
回答 1
Stack Overflow用户
发布于 2019-03-18 00:10:42
我的天，这感觉有点过头了。
在后台，许多对象被实例化来完成这样一个简单的任务。
Stream在这里管理elements的流。
也是
.findAny();
.findFirst();实际上并不适合这种情况，主要是因为它们返回一个Optional<T>，即使您知道结果总是存在的，您也必须处理它。
在Optional.of上，为什么选择Optional？我的意思是，这里没有什么可选的，你知道它的价值在那里。这是误导性的。在错误的地方使用Optional一次，你就会把它弄得到处都是。
有多个连续的方法调用从一个对象B开始创建一个对象A并没有错。关键是immutability和中间态。只需使用不可变的定义，就可以了。
请记住，Java不是函数优先的(仍然是)。
无论如何，您可能会对RxJava或FunctionalJava感兴趣。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/55208952
复制相关文章
相似问题
腾讯云开发者
