我有一个方法
public String getSomething(Optional<String> name) {
StringBuilder something = new StringBuilder("Hello");
name.ifPresent(n -> something.append(n));
return something.toString();
}
我使用IntelliJ,它抱怨你不应该使用Optionals作为参数而只能作为返回类型。我还读到你想要避免函数式编程中的副作用,你不应该操纵对象。
所以我一直在想的是,如果做起来不是更好
public String getSomething(String name) {
StringBuilder something = new StringBuilder("Hello");
if (name != null) {
something.append(name);
}
return something.toString();
}
使用Optional有什么好处吗?我能看到的一个好处是该方法告诉您该参数是可选参数。
答案 0 :(得分:0)
最好传递Optional
而不是null
。 IntelliJ试图过于规范。假设是,在呼叫站点,你做了:
Optional<String> nameOpt = ...
nameOpt.ifPresent(name -> getSomething(name));
是的,理想的。希望nameOpt
这里没有参数...
您可以使用地图:
Optional<String> sOpt = nameOpt.map(this::getSomething);
与
public String getSomething(String name) {
StringBuilder something = new StringBuilder("Hello");
something.append(name);
return something.toString();
}
这是完美的功能,IntelliJ也会喜欢它。
使用java 9,Optional的功能将会增长。
看来实际问题是:有一个可能为null的String参数, 我们应该处理:
Optional.ofNullableparameter)
进一步,或传递参数。
他们的可选地图可以安全地链接处理可能的String并返回其他一些可选:
// Get the length of the uppercased parameter, when it exists:
Optional<Integer> lengthOpt = Optional.ofNullable(parameter)
.map(s -> s.toUpperCase(Locale.DE))
.map(String::length);
如果参数是“Goßlung” - “GOSSLUNG” - Optional.of(8)。
(该示例应使用OptionalInt,但这将是相同的。)
答案 1 :(得分:0)
在这种情况下传递Optional
是正常的,但你可以写一些类似
String nullableName = null;
Optional<String> name = Optional.ofNullable(nullableName);
StringBuilder something = new StringBuilder("Hello");
// getSomething equivalent
name.map(something::append).orElse(something);
您映射非空值或仅返回构建器
答案 2 :(得分:0)
处理此问题的最佳方法是告诉调用者不要首先传递null。
这实际上是Java SE的大部分工作原理。例如,如果您尝试new URL(null)
,您将获得例外。 new BigDecimal(null)
,System.getProperty(null)
,ImageIO.read(null)
以及其他许多内容也是如此。
你的方法也应该这样做。事实上,there exists a method就是出于这个目的:
public String getSomething(String name) {
Objects.requireNonNull(name,
"This method may not be called with a null argument.");
调用代码应该对null值的存在负责,并且应该避免使用null调用方法。理想情况下,调用代码应该将null视为异常值,并且应该尽可能避免处理空值。