Y a-t-il une raison ou une circonstance pour laquelle je devrais utiliser object == null plutôt que Objects.isNull() dans une application de type si déclaration ?
Oui, l'une des raisons est de garder le code simple. A l'intérieur de si déclaration object == null
est claire et bien connue. Une faute de frappe, par exemple, ne peut donner lieu à aucun comportement erroné.
Si j'ai bien compris, Objects.isNull() éliminerait le risque d'attribuer accidentellement une valeur nulle à l'objet en omettant le deuxième =.
S'il y a un if (object = null) {}
con omis =
il ne compilera pas ou génèrera un avertissement en cas de Boolean
objet ! En fait, il n'y a aucune raison d'utiliser Objects.isNull(object)
plus object == null
à l'intérieur si déclaration . Voici les deux variantes côte à côte :
if (object == null) {
}
if (Objects.isNull(object)) {
}
Objects.isNull() doit-il être limité aux seuls prédicats ?
On pourrait dire que oui, il est limité aux prédicats exclusivement, bien qu'il n'y ait pas d'obstacle technique à l'utilisation de l'outil de gestion des prédicats. Objects.isNull()
partout.
A partir de la public static boolean isNull(Object obj)
de la méthode :
@apiNoteCette méthode existe pour être utilisée en tant que java.util.function.Predicate, filter(Objects::isNull)
Ainsi, si vous utilisez la méthode comme pas un prédicat, vous utilisez en fait une expression plus complexe et plus lourde que la simple expression object == null
.
Voici un extrait qui permet de comparer les avantages de Objects.isNull(object)
List<String> list = Arrays.asList("a", "b", null, "c", null);
// As ready-made predicate
long countNullsWithPredicate = list.stream().filter(Objects::isNull).count();
// Lambda
long countNullsWithLambda = list.stream().filter(object -> object == null).count();
// Reimplement the Objects::isNull predicate
long countNullsWithAnonymous = list.stream().filter(new Predicate<Object>() {
@Override
public boolean test(Object obj) {
return obj == null;
}
}).count();
0 votes
Il y a aussi Objects.requireNonNull(T obj) ; btw
4 votes
Si tout ce qui vous préoccupe est une affectation accidentelle, vous pouvez simplement utiliser
if(null == variable)
de manière cohérente1 votes
@Holder, quelle affectation accidentelle doit-on craindre ? Il s'agit de Java. Vous obtiendrez une erreur de type.
1 votes
@LouisWasserman Pas si
variable
es unBoolean
.2 votes
@AlexisC, ce serait un problème dans une minuscule, minuscule nombre de cas : votre variable doit être d'un type très spécifique, y il faut faire une faute de frappe très spécifique, y vous ne pouvez pas utiliser un IDE ou une analyse de compilateur qui vous le signalerait (comme le feraient presque tous les IDE). Je suis tout à fait à l'aise pour ne pas m'inquiéter de ce cas.
2 votes
Au travail, j'ai vu de nombreux cas de null==objet . Lorsque j'ai posé la question, on m'a répondu que c'était pour éviter les affectations accidentelles de valeurs nulles. Sur la base des commentaires et des réponses fournis ici, je serais enclin à croire qu'il s'agit d'une question de goût.