为什么我应该将Boolean作为参数而不是“boolean”传递?

时间:2010-04-26 18:49:51

标签: java java-ee

一位同事让我将签名从使用原语“boolean”更改为使用归类的“Boolean”。他没有提供很好的解释原因?

你们有没有人听说过这个问题,你们中有谁可以解释为什么重要或无关紧要?

编辑:他提到这是公共方法的好习惯。

使用该字段只是一个标志,告诉我是否要调用一个或另一个流,具体取决于它是真还是假。

10 个答案:

答案 0 :(得分:26)

与数据库有关吗?如果数据库中有布尔值,则它可以包含三个值之一 - true,false和null。布尔对象可以让你模仿这种行为。

基本上,这是一个问题,你是否想要处理“null”作为潜在的输入值。

答案 1 :(得分:22)

实际上我倾向于错误地传递small-b boolean,因为我知道原始布尔值永远不会为null。我确信使用布尔类型有正当理由,但我想考虑它在每种情况下的使用。

答案 2 :(得分:8)

实际上,一般来说,除非有特殊原因,否则使用常规基元是一种好习惯。虽然你需要移动很多物体才能真正发挥作用,但它会稍微快一点/少浪费。

为了回应你的编辑,我从来没有听说过这是公共方法的好习惯。在Josh Bloch经常引用的Effective Java中,有一个完整的项目“Prefer primitive types to boxed primitives”(第49项,如果你能得到一份副本)。听起来你的具体案例没有理由支持使用big-b布尔值,并且使用对象会产生陷阱,例如与旧代码的交互不良,例如,使用==而不是equals()(对于原始人来说甚至是不可能的。)

答案 3 :(得分:4)

布尔值相对于原始布尔值的主要优点是它们允许您具有空值。这对返回值特别有效,但有时可用于Java中的“可选”参数。

确保您的JavaDocs(和代码)可以处理null

答案 4 :(得分:2)

我通常会尝试尽可能使用原始布尔值。

我认为开发人员想要布尔类的唯一可能性是装箱/拆箱(但我认为你想要尽可能防止装箱/拆箱而不是在任何地方鼓励它)以及空值的可能性

答案 5 :(得分:2)

如果你控制接口的两面(即调用代码和被调用的方法),那么你应该只是一致。如果你强制编译器为你自动代替变量,你实际上会产生一些开销。

如果所讨论的方法是具有相似签名的一组方法之一,并且所有其他方法在boolean所在的位置传递某种对象,那么使用对象而不是原语可能只是是一个更加一致的问题。

编辑:重新阅读问题,如果boolean参数真的只是控制if(这正是原语所在的那个),那么使用对象形式就是浪费CPU时间和内存。我想不出一个明智的理由为什么它应该是一个对象而不是一个原始的。

答案 6 :(得分:2)

从未听说过有Boolean优于boolean的正当理由。

如果有机会,总是坚持使用原语。布尔变量可以是null;因此可能会在您的方法中引入意外行为。您的同事可能有一些基于程序实现/逻辑的具体原因。

答案 7 :(得分:1)

保持简单。使用布尔:

  • 增加了一层额外的复杂性
  • 获取true / false状态boolean并将其转换为true / false / null状态变量
  • 如果用作逻辑标志,
  • 没有任何优势(假设BlairHippo没有提到数据库交互)
  • 可能需要额外的代码行来支持Java 1.4中的box / unbox布尔值

答案 8 :(得分:0)

如果使用布尔值,则可以将布尔值或布尔值传递给方法

public void setX(boolean b) //only takes boolean

public void setX(Boolean b) //takes Boolean or boolean

这是由于布尔值自动装入函数中。

编辑:自动装箱仅适用于1.5 +

答案 9 :(得分:0)

您是否在应用中使用任何类型的数据绑定框架?我最近不得不处理一个案例,其中模型对象中的boolean需要绑定到表单。表单中的字段是必填字段,但我们不希望将值默认为truefalse(因为对于用户来说,为特定情况选择正确的值非常重要,如果有的话是一个默认值,你很容易得到很多不正确的值。)但是,在验证对象之前,必须将表单中的值绑定到它。当然,如果用户没有选择值,它将尝试将null绑定到该字段,并且在绑定期间将抛出异常。因此,我们将其更改为Boolean,以便null可以暂时绑定到该字段,然后验证可以报告该字段是必需的。

相关问题