Quand faut-il utiliser des valeurs nulles de booléen?

Java booleanpermet des valeurs de trueet falsetout Boolean permet true, falseet null. J'ai commencé à convertir mes booleans en Booleans. Cela peut provoquer des plantages dans des tests tels que

Boolean set = null;
...
if (set) ...

tandis que le test

if (set != null && set) ...

semble artificiel et sujet aux erreurs.

Quand, le cas échéant, est-il utile d'utiliser Booleans avec des valeurs nulles? Si jamais, quels sont les principaux avantages de l'objet enveloppé?

MISE À JOUR: Il y a eu tellement de réponses précieuses que j'en ai résumé certaines dans ma propre réponse. Je suis au mieux un intermédiaire en Java donc j'ai essayé de montrer les choses que je trouve utiles. Notez que la question est "mal formulée" (le booléen ne peut pas "avoir une valeur nulle") mais je l'ai laissée au cas où d'autres auraient la même idée fausse

Utilisez booleanplutôt que Booleanchaque fois que vous le pouvez. Cela évitera de nombreux NullPointerExceptions et rendra votre code plus robuste.

Boolean est utile, par exemple

• pour stocker des booléens dans une collection (List, Map, etc.)
• pour représenter un booléen nullable (provenant d'une colonne booléenne nullable dans une base de données, par exemple). La valeur nulle peut signifier "nous ne savons pas si c'est vrai ou faux" dans ce contexte.
• chaque fois qu'une méthode a besoin d'un Object comme argument, et vous devez passer une valeur booléenne. Par exemple, lorsque vous utilisez la réflexion ou des méthodes comme MessageFormat.format().

Je ne l'utilise presque jamais Booleancar sa sémantique est vague et obscure. Fondamentalement, vous avez une logique à 3 états: vrai, faux ou inconnu. Parfois, il est utile de l'utiliser lorsque, par exemple, vous avez donné à l'utilisateur le choix entre deux valeurs et que l'utilisateur n'a pas du tout répondu et que vous voulez vraiment connaître cette information (pensez: colonne de base de données NULLable).

Je ne vois aucune raison de convertir de booleanen Booleancar cela introduit une surcharge de mémoire supplémentaire, une possibilité NPE et moins de frappe. En général, j'utilise maladroit BooleanUtils.isTrue()pour rendre ma vie un peu plus facile avec Boolean.

La seule raison de l'existence de Booleanest la possibilité d'avoir des collections de Booleantype (les génériques ne le permettent pas boolean, ainsi que toutes les autres primitives).

Wow, que diable? Est-ce juste moi ou est-ce que toutes ces réponses sont fausses ou du moins trompeuses?

La classe Boolean est un wrapper autour du type primitif booléen. L'utilisation de ce wrapper est de pouvoir passer un booléen dans une méthode qui accepte un objet ou générique. Ie vecteur.

Un objet booléen ne peut JAMAIS avoir une valeur nulle. Si votre référence à un booléen est nulle, cela signifie simplement que votre booléen n'a jamais été créé.

Vous trouverez peut-être cela utile: http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/lang/Boolean.java

Une référence booléenne nulle ne doit être utilisée que pour déclencher une logique similaire à laquelle vous avez une autre référence nulle. L'utiliser pour une logique à trois états est maladroit.

EDIT: remarquez, c'est Boolean a = true;une déclaration trompeuse. Cela équivaut vraiment à quelque chose de plus proche de Boolean a = new Boolean(true); S'il vous plaît voir autoboxing ici: http://en.wikipedia.org/wiki/Boxing_%28computer_science%29#Autoboxing

C'est peut-être de là que vient une grande partie de la confusion.

EDIT2: Veuillez lire les commentaires ci-dessous. Si quelqu'un a une idée de la façon de restructurer ma réponse pour l'intégrer, faites-le.

Il y a trois raisons rapides:

• pour représenter les valeurs booléennes de la base de données, qui peuvent être true, falseounull
• pour représenter les xsd:booleanvaleurs de XML Schema déclarées avecxsd:nillable="true"
• pour pouvoir utiliser des types génériques: List<Boolean>- vous ne pouvez pas utiliserList<boolean>

RÉPONSE À LA PROPRE QUESTION: J'ai pensé qu'il serait utile de répondre à ma propre question car j'ai beaucoup appris des réponses. Cette réponse vise à aider ceux - comme moi - qui n'ont pas une compréhension complète des problèmes. Si j'utilise un langage incorrect, veuillez me corriger.

• La "valeur" nulle n'est pas une valeur et est fondamentalement différente de trueet false. C'est l'absence de pointeur sur les objets. Par conséquent, penser que booléen a une valeur de 3 est fondamentalement faux

• La syntaxe de Boolean est abrégée et masque le fait que la référence pointe vers Objects:

  Boolean a = true;

cache le fait que truec'est un objet. D'autres affectations équivalentes peuvent être:

Boolean a = Boolean.TRUE;

ou

Boolean a = new Boolean(true);

• La syntaxe abrégée

  if (a) ...

est différent de la plupart des autres affectations et cache le fait que a pourrait être une référence d'objet ou une primitive. Si un objet, il est nécessaire de tester pour nulléviter NPE. Pour moi, il est psychologiquement plus facile de se souvenir de ceci s'il y a un test d'égalité:

if (a == true) ...

où nous pourrions être invités à tester null. Ainsi, la forme raccourcie n'est sûre que lorsqu'elle aest primitive.

Pour moi, j'ai maintenant les recommandations:

• N'utilisez jamais null pour une logique à 3 valeurs. N'utilisez que vrai et faux.
• NE JAMAIS revenir Booleand'une méthode telle qu'elle pourrait l'être null. Seulement revenir boolean.
• Utiliser uniquement Booleanpour encapsuler des éléments dans des conteneurs ou des arguments vers des méthodes où des objets sont requis

Les classes wrapper pour les primitives peuvent être utilisées là où des objets sont requis, les collections sont un bon exemple.

Imaginez que vous ayez besoin pour une raison quelconque de stocker une séquence de booleandans un ArrayList, cela peut être fait en boxant booleandansBoolean .

Il y a quelques mots à ce sujet ici

De la documentation:

Comme tout programmeur Java le sait, vous ne pouvez pas mettre un int (ou une autre valeur primitive) dans une collection. Les collections ne peuvent contenir que des références d'objet, vous devez donc placer les valeurs primitives dans la classe wrapper appropriée (qui est Integer dans le cas de int). Lorsque vous retirez l'objet de la collection, vous obtenez l'entier que vous avez mis; si vous avez besoin d'un int, vous devez déballer l'entier à l'aide de la méthode intValue. Toute cette boxe et déballage est pénible et encombre votre code. La fonction de boîte automatique et de déballage automatise le processus, éliminant la douleur et l'encombrement.

http://docs.oracle.com/javase/1.5.0/docs/guide/language/autoboxing.html

Booleanwrapper est utile lorsque vous voulez savoir si la valeur a été attribuée ou non en dehors de trueet false. Il a les trois états suivants:

• Vrai
• Faux
• Non défini qui est null

Alors qu'il booleann'a que deux états:

• Vrai
• Faux

La différence ci-dessus le rendra utile dans les listes de Booleanvaleurs, qui peuvent avoir True, Falseou Null.

Je suppose que dans certains cas, vous devriez avoir un mécanisme pour distinguer un champ booléen qui a déjà défini une valeur ou non.

Le but principal de Boolean est la valeur nulle. La valeur nulle indique que cette propriété n'est pas définie , par exemple, prenez la colonne Nullable de la base de données.

Si vous avez vraiment besoin de convertir tout le booléen primitif en booléen wrapper, vous pouvez utiliser ce qui suit pour prendre en charge l'ancien code:

Boolean set = Boolean.FALSE; //set to default value primitive value (false)
...
if (set) ...

Il existe de nombreuses utilisations de la valeur ** null ** dans le wrapper booléen! :)

Par exemple, vous pouvez avoir dans un formulaire un champ nommé "newsletter" qui indique si l'utilisateur veut ou ne veut pas une newsletter de votre site. Si l'utilisateur ne sélectionne pas de valeur dans ce champ, vous souhaiterez peut-être implémenter un comportement par défaut dans cette situation (envoyer? Ne pas envoyer ?, question à nouveau ?, etc.). Clairement, non défini (ou non sélectionné ou ** nul **), n'est pas la même chose que vrai ou faux.

Mais, si "non défini" ne s'applique pas à votre modèle, ne changez pas la primitive booléenne;)

Dans une définition stricte d'un élément booléen, il n'y a que deux valeurs. Dans un monde parfait, ce serait vrai. Dans le monde réel, l'élément peut être manquant ou inconnu. En règle générale, cela implique une entrée de l'utilisateur. Dans un système basé sur un écran, il pourrait être forcé par une modification. Dans un monde par lots utilisant une base de données ou une entrée XML, l'élément peut facilement manquer.

Ainsi, dans le monde non parfait dans lequel nous vivons, l'objet booléen est génial en ce sens qu'il peut représenter l'état manquant ou inconnu comme nul. Après tout, les ordinateurs modélisent simplement le monde réel et doivent tenir compte de tous les états possibles et les gérer avec des exceptions (surtout parce qu'il existe des cas d'utilisation où lancer l'exception serait la bonne réponse).

Dans mon cas, l'objet booléen était la réponse parfaite car le XML d'entrée avait parfois l'élément manquant et je pouvais toujours obtenir une valeur, l'attribuer à un booléen puis vérifier la valeur null avant d'essayer d'utiliser un test vrai ou faux avec lui .

Juste mes 2 cents.

Pour toutes les bonnes réponses ci-dessus, je vais juste donner un exemple concret dans la HttpSessionclasse de servlet Java . J'espère que cet exemple vous aidera à clarifier une question que vous vous posez peut-être encore.

Si vous devez stocker et récupérer des valeurs pour une session, vous utilisez la méthode setAttribute(String, Object) et getAttribute(String, Object). Donc pour une valeur booléenne, vous êtes obligé d'utiliser la classe Boolean si vous souhaitez la stocker dans une session http.

HttpSession sess = request.getSession(false);
Boolean isAdmin = (Boolean) sess.getAttribute("admin");
if (! isAdmin) ...

La dernière ligne provoquera un NullPointerExceptionsi les valeurs d'attribut ne sont pas définies. (ce qui est la raison qui m'a conduit à ce post). L'état logique 3 est donc là pour rester, que vous préfériez l'utiliser ou non.

Le meilleur moyen serait d'éviter complètement les booléens, car chaque booléen implique que vous avez une instruction conditionnelle n'importe où ailleurs dans votre code (voir http://www.antiifcampaign.com/ et cette question: Pouvez-vous écrire un algorithme sans instruction if ? ).

Cependant, de manière pragmatique, vous devez utiliser des booléens de temps en temps, mais, comme vous l'avez déjà découvert par vous-même, gérer les booléens est plus sujet aux erreurs et plus fastidieux. Je suggérerais donc d'utiliser des booléens dans la mesure du possible. Les exceptions à cela pourraient être une base de données héritée avec des colonnes booléennes nullables, bien que j'essaierais de cacher cela également dans mon mappage.

Boolean peut être très utile lorsque vous avez besoin de trois états. Comme dans les tests logiciels, si le test est réussi, envoyez true, en cas d'échec, envoyez false et si le cas de test est interrompu, envoyez null, ce qui indiquera que le cas de test n'a pas été exécuté.