¿Por qué debería pasar Boolean como un parámetro en lugar de "boolean"?

Question

Un compañero de trabajo me pidió que cambie una firma de usar un "booleano" primitivo a usar un "booleano" clasificado. Él no ofreció una muy buena explicación ¿por qué?

¿Alguno de ustedes ha oído hablar de esto y alguno de ustedes puede explicar por qué es importante o no?

Editar: mencionó que era una buena práctica para los métodos públicos.

El uso del campo es solo una bandera que me dice si llamar a un flujo u otro dependiendo de si es verdadero o falso.

Answer 1

En realidad, tiendo a errar en el lado de pasar small-b boolean en su lugar, porque sé que un booleano primitivo nunca va a ser nulo. Estoy seguro de que hay razones válidas para usar el tipo booleano, pero me gustaría pensar en su uso en cada caso.

Answer 2

¿Está relacionado con la base de datos? Si tiene un valor booleano en una base de datos, puede contener uno de TRES valores: verdadero, falso y nulo. El objeto booleano te permite imitar ese comportamiento.

Básicamente, se trata de si desea tratar con "nulo" como un posible valor de entrada.

Answer 3

En realidad, en general, es una buena práctica usar primitivas regulares a menos que haya una razón específica para no hacerlo. Será un poco más rápido/menos derrochador, aunque necesitarás mover muchos objetos para que eso realmente importe.

En respuesta a su edición, nunca escuché que sea una buena práctica para los métodos públicos. En el Java Efectivo frecuentemente citado por Josh Bloch, hay un ítem completo "Prefiere tipos primitivos a primitivas en caja" (ítem 49, si puedes conseguir una copia). Parece que su caso específico no tiene ningún motivo para utilizar un booleano big-b, y el uso de objetos crea riesgos como una mala interacción con el código anterior que, por ejemplo, usa == en lugar de equals() (que ni siquiera es posible para un primitivo)

Answer 4

Normalmente trato de utilizar el booleano primitivo siempre que sea posible.

La única posibilidad que tengo para un desarrollador de querer la clase Boolean es boxing/unboxing (pero creo que querría evitar el boxeo/unboxing siempre que sea posible en lugar de alentarlo en todas partes) y la posibilidad de null valores.

Answer 5

Si controla ambos lados de la interfaz (es decir, el código de llamada y el método llamado), entonces simplemente debe ser coherente. En realidad incurre en un poco de sobrecarga si fuerza al compilador a que autoboxique la variable por usted.

Si el método en cuestión es uno de un conjunto de métodos con firmas similares, y todos los demás pasan un objeto de algún tipo en la posición donde su boolean va, entonces usar un objeto en lugar de un primitivo podría ser simplemente una cuestión de ser un poco más consistente.

EDIT: Re-leer la pregunta, en caso de que boolean parámetro es en realidad sólo existe para controlar un if (que es exactamente lo que el primitivo es allí para), a continuación, utilizando la forma de objeto es simplemente una pérdida de tiempo de CPU y de memoria . No puedo pensar en una razón sensata por la que debería ser un objeto en lugar de un primitivo.

Answer 6

La ventaja principal de Boolean sobre booleanos primitivos es que le permiten tener un valor nulo. Esto es particularmente efectivo para los valores de retorno pero a veces se puede usar para un argumento "opcional" en Java.

asegurarse de que su JavaDocs (y código) pueden hacer frente a la nula

Answer 7

Nunca

oído de cualquier razón válida para preferir Boolean sobre boolean.

Dada la oportunidad, siempre se adhieren a los primitivos. Las variables booleanas pueden ser null; y así puede introducir un comportamiento inesperado en su método. Su compañero de trabajo puede tener algunas razones específicas basadas en la implementación/lógica del programa.

Answer 8

Si utiliza Boole, entonces Puede pasar un valor lógico o un booleano con el método

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

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

Esto se debe a la autoboxing de los booleanos en la función.

EDITAR: El autoboxing sólo funciona en 1.5 +

Answer 9

que sea sencillo. El uso de Boole:

• añade una capa adicional de complejidad
• necesita un verdadero booleano Estado/falso y lo convierte en un estado de verdadero/falso/null variables
• no ofrece ventajas si se usa como una bandera lógica (suponiendo que no hay interacción de base de datos como se ha mencionado por BlairHippo)
• requiere potencialmente líneas adicionales de código para la caja/booleanos Unbox en Java 1,4

Answer 10

¿está utilizando cualquier tipo de marco de enlace de datos en su aplicación? Recientemente tuve que lidiar con un caso en el que un boolean en un objeto modelo tenía que estar vinculado a un formulario. El campo en el formulario era obligatorio, pero no deseábamos establecer el valor predeterminado en true o false (porque era importante para el usuario elegir el valor correcto para el caso específico; si existía un valor predeterminado, fácilmente obtener muchos valores incorrectos.) Sin embargo, antes de poder validar el objeto, los valores del formulario tenían que estar vinculados a él. Por supuesto, si el usuario no hubiera seleccionado un valor, intentaría enlazar null al campo, y se lanzaría una excepción durante el enlace. Así que lo cambiamos a Boolean para que null se pueda vincular al campo temporalmente, y luego la validación podría informar que el campo fue requerido.