我是java新手,之前使用过php、python和js。最近使用 python,所以习惯了“if myVar is None:”之类的东西。这是我的问题:我从某个库获取语言环境作为可选,我只需要返回一种语言,或者如果发生超时或一些错误等,则需要返回其他内容。然后我需要将语言传递给某个对象(上下文),并且稍后将上下文转换为请求的参数。所以我做了类似的事情
String getLanguage(){
try {
Optional<String> locale = getLocale();
if (locale.isPresent()){logging, locale.get()-to-language conversion, language validation,
logging, return language}
else (logging, return null;)
} except {logging error, return null};
}
Context c = new Context();
c.setSomething(something);
c.setLanguage(getLanguage());
and somewhere later:
Request r = new Request();
r.addParam(something, c.getSomething());
if (c.getLanguage() != null) {r.addParam(language, c.getLanguage())
我收到了使用可选重写所有内容的建议。将我的第一个方法替换为类似的方法。
Optional<String> getLanguage(){
try {
Optional<String> locale = getLocale();
return locale.ifPresent(logging)
.map(locale-to-language conversion, language validation, logging, return language}
.orElse(logging, return Optional.isEmpty())
} except {logging error, return Optional.isEmpty()};
}
and then somewhere later c.getLanguage().ifPresent(x -> r.addParam(language, x))
我以前从未使用过Optional,所以我很高兴学习新东西,并且我认为对于习惯Optional的人来说我的代码不好。从另一边我看到这里的Optional在这里是多余的-我需要修改我的数据类Context来处理Optional,我的map()和orElse()很丑陋-它们有2-5行代码等,还有单元测试需要返工。所以,我的问题是——这些对可选的改变是否增加了一些好处,或者我们只是在不假思索地追随时尚。
最佳答案
So, my question is - are those changes to Optional adding some benefits ...
这两种方法肯定都有优点和缺点:
从可选
方面来看,主要的“优点”是消除错误的主要来源;即 NPE 是由于未正确处理可能返回的 null
引起的。主要的“缺点”是使用 Optional
的代码冗长,并且它实际上并没有消除所有错误;例如如果您在“空”Optional
上调用 Optional.get
,您将收到异常。
其他问答更详细:
- Null check vs Optional is present check
- Uses for Optional
- Optional vs. null. What is the purpose of Optional in Java 8?
- Is using Optional.ofNullable as a replacement for the ternary operator a good practice?
... or we are just following fashion without thinking.
这是一个不同的问题!
现在我想有些人可能会不假思索地使用Optional
,但我没有看到太多证据。显然,有利有弊,需要思考。
所以你真的应该问(你自己!)>>你<<是否只是不假思索地追随时尚?或者换句话说,您只是将其视为(所谓的)“最佳实践”,还是根据上下文在两种方法之间做出合理的选择?
<小时/>I have got a suggestion to rewrite everything [in my example] using
Optional
.
这是我的建议。
- 在版本控制系统中创建一个分支。
- 在分支中,将您的 API 方法更改为使用
可选
,并更改代码中使用该 API 方法的所有位置。 - 做出判断:这是否有所改善?这些努力值得吗?
- 如果该 API 目前或即将被其他人的代码使用,也请询问他们的意见。
- 决定是否继续,执行决定,然后继续下一个问题。
如果这听起来工作量太大,另一种选择是悄悄地忽略该建议。
无论哪种方式,我们(StackOverflow 社区)都无法为您做出决定。我们没有上下文1,即使有,也会有各种各样的意见,并且没有明确的正确答案。
<小时/>1 - 例如,没有语言环境和可确定语言的可能性有多大。整个应用程序应该对此做什么?是否应该纾困?它应该替代默认值吗?可以在这里替换默认值吗?我们看不到“大局”。
关于Java,当返回和使用 "null"时比Optional更好?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/60123380/