Java 作为输入参数的可选变量

我读书。但是关于

可选（Int | Long | Double）

，有反对将它们用作输入参数的参数吗

---

正如我正确理解的那样，它们不能是空的，而是带有null（输入参数中反对

可选
的主参数），但可能还有其他暗礁吗？我应该将
optionant
或
Integer
与
null
一起使用，而不是
null
值吗
 这种不使用选项作为方法参数的想法不仅针对
Optional
，而且针对所有类型的选项

当你说：

正如我正确理解的，它们不能是空的，而是空的
（输入参数中反对
可选
的主参数）

首先也是最重要的是，让我们把术语弄对，当一个
可选的
包含一个非空引用时，我们说它存在，否则我们说
可选的
是空的或不存在的。您不应该说
可选的
包含null

无论是
T
类型的对象的容器还是基元类型的对象，所有选项都可以为空

例如，如果查看类文档，它会说：

包含或不包含int值的容器对象。如果
值存在时，isPresent（）将返回true，getAsInt（）将返回true
返回值

我的

当可选项不包含int值时，则为空可选项

我应该使用Optionant还是带有null和notnull值的整数

至于使用
optionant
或
Integer
实际上取决于您的使用
案例


与类型为
T
的容器和
基元类型它们是描述性的，可以应用不同的
提取值（如果存在）或执行某些操作的操作类型
如果缺席的话，我会去的
任何
整型
字段都可以分配空值
可以使用
Integer
作为返回类型的任何方法返回
null
optionant
字段（有争议的）不应被分配为
null
，因为这首先违背了使用Optional的全部目的
在任何返回类型为optionant的方法中，都不应再次返回
null
，因为它首先会破坏使用Optional的整个目的

等等

此外，有些人实际上不鼓励使用基本选项，因为它们缺少
map
、
flatMap
和
过滤方法

本质上，没有规则总是使用Opthor或VARA，而是选择最适合您需要的API。
 < P>，有3件事要考虑，将<代码> OptionalInt < /C> >代码> >整数< /C> >或<代码> int >代码>为方法（或在此类中具有属性）。
通常传递一个
整数
不是最好的主意，因为您需要检查
null
。实际上，有些人希望这样做，因为它可以表示3种状态-
未知/真/假
——我仍然不喜欢它（在这种情况下，
枚举
更适合）

因此，从语义上讲，将
null
传递给接受
整数的方法可能意味着-我不希望出现这个值。但是，提供这种方法的代码应该负责处理这个问题；一个更好的方法是使用重载方法，这些方法不将其作为输入，从而在IMO中明确说明此参数不是必须的

好的，传递
int
是否更好？是的，有点。思考一下ORM（休眠）；有些情况下，某个属性可以是
int
或
Integer
——在这种情况下，我倾向于
Integer
；主要是因为
int
有一个默认值或
zero
——我更希望代码使用
NullPointer
失败，而不是保留过时的值：zero可能是一个完全有效的业务值，但如果我们不打算将其作为
zero
，该怎么办？当然，这意味着数据库和服务层需要适当的验证，等等——我不打算详细讨论这些细节

那么，将
optionant
传递给以前接受
整数的方法怎么样？您仍然需要检查它是否存在（是否为
null
？），您仍然需要检查它是否为空，并采取相应的步骤。这通常意味着您需要不同的代码路径，这取决于该参数——在这种情况下，必须传入更具描述性的内容。你仍然可以这样做，但如果到时候，你还需要一个条件呢
Optionant
无法处理此问题，因此需要进行重大重构

但是可选的返回类型非常棒。如果一个方法返回一个
整数
你检查了多少次它是否为空？另一方面，如果一个方法返回
optionant
，你必须考虑万一它丢失了该怎么办，因为否则你无法检索它的值：除非
isPresent？
或任何其他方法，如
orElse/orElseGet
等。
…并且它们没有
null
，即使传递了该值。它们是空的，如果您试图获取值，它们将爆炸。我无法理解您的
可选
可以
！isPresent
，
isPresent
但是
null
，和
isPresent（
和
！=null
，但是
可选的
不能是
isPresent
和
null
，因为原始类型不能是
null
@user1244932”
可选的
可以是
isPresent
但是空的--不，它不能。可选的
值（如果存在）是非空的。请参阅--“A c