这是
Java 8中可选类型的有效(预期)用法吗？
class Foo {
private final Integer id;
private final String name;
private final String countryCode;
Foo(final Integer id,final String name,final String countryCode) {
this.id = id;
this.name = name;
this. countryCode = countryCode;
}
public String getName() {
return name;
}
public String getCountryCode() {
return countryCode;
}
}
class FooSrv {
private Optional<Foo> getFoo(final Integer id) {
return id != null && id == 1 ? Optional.of(new Foo(id,"Bar","US")) : Optional.empty();
}
private boolean isFoovalid(final Integer id) {
return getFoo(id)
.filter(f -> "Bar".equals(f.getName()) && "US".equals(f.getCountryCode()))
.map(f -> true)
.orElse(false);
}
}
解决方法
我会再来这个摆动.
这是否有效使用？是的,狭义的是它编译并产生你期待的结果.
这是预期用途吗？不,现在,有时候,事情发现超越了他们原来的用处,如果这样做,伟大的事情.但是对于可选,我们发现通常情况并不好.
Brian Goetz和我讨论了可选在JavaOne 2015谈话中的一些问题,API设计与Java 8 Lambdas和Streams：
> link to video
> link to slides
可选的主要用途如下：(幻灯片36)
Optional is intended to provide a limited mechanism for library method return types where there is a clear need to represent “no result,” and where using
nullfor that is overwhelmingly likely to cause errors.
从可选中链接方法的能力无疑非常酷,在某些情况下,它可以减少条件逻辑的混乱.但是经常这样做并不奏效.典型的代码气味是,而不是使用方法链接的代码来处理从某些方法返回的可选项,它从可空的东西创建一个可选项,以链接方法和避免条件.这是一个在行动中的例子(也来自我们的演示文稿,幻灯片42)：
// BAD
String process(String s) {
return Optional.ofNullable(s).orElseGet(this::getDefault);
}
// GOOD
String process(String s) {
return (s != null) ? s : getDefault();
}
使用Optional的方法更长,大多数人发现它比传统代码更加模糊.不仅如此,它创造了额外的垃圾没有好的理由.
底线：只是因为你可以做某事并不意味着你应该做.