Opérateur de raccourci «or-assignment» (| =) en Java

J'ai une longue série de comparaisons à faire en Java et j'aimerais savoir si une ou plusieurs d'entre elles s'avèrent vraies. La chaîne de comparaisons était longue et difficile à lire, alors je l'ai interrompue pour plus de lisibilité et je suis automatiquement allée utiliser un opérateur de raccourci |=plutôt que negativeValue = negativeValue || boolean.

boolean negativeValue = false;
negativeValue |= (defaultStock < 0);
negativeValue |= (defaultWholesale < 0);
negativeValue |= (defaultRetail < 0);
negativeValue |= (defaultDelivery < 0);

Je m'attends negativeValueà être vrai si l'une des valeurs par défaut <quelque chose> est négative. Est-ce valable? Fera-t-il ce que j'attends? Je n'ai pas pu le voir mentionné sur le site de Sun ou sur stackoverflow, mais Eclipse ne semble pas avoir de problème avec cela et le code se compile et s'exécute.

De même, si je voulais effectuer plusieurs intersections logiques, pourrais-je utiliser à la &=place de &&?

le |= est un opérateur d'affectation de composé ( JLS 15.26.2 ) pour l'opérateur logique booléen |( JLS 15.22.2 ); à ne pas confondre avec le conditionnel-or ||( JLS 15.24 ). Il existe également &=et ^=correspondant à la version d'affectation composée de la logique booléenne &et ^respectivement.

En d'autres termes, pour boolean b1, b2, ces deux sont équivalents:

 b1 |= b2;
 b1 = b1 | b2;

La différence entre les opérateurs logiques ( &et |) et leurs équivalents conditionnels ( &&et ||) est que les premiers ne "court-circuitent" pas; ce dernier le font. C'est:

• &et | toujours évaluer les deux opérandes
• &&et ||évaluer le bon opérande de manière conditionnelle ; l'opérande de droite n'est évalué que si sa valeur peut affecter le résultat de l'opération binaire. Cela signifie que l'opérande correct n'est PAS évalué lorsque:
  • L'opérande gauche de &&évalue àfalse
    • (car peu importe ce que le bon opérande évalue, l'expression entière est false)
  • L'opérande gauche de ||évalue àtrue
    • (car peu importe ce que le bon opérande évalue, l'expression entière est true)

Donc, pour revenir à votre question initiale, oui, cette construction est valide, et bien que |= n'est pas exactement un raccourci équivalent pour =et ||, elle calcule ce que vous voulez. Comme le côté droit de l' |=opérateur dans votre utilisation est une simple opération de comparaison d'entiers, le fait que| ne court-circuite pas est insignifiant.

Il existe des cas où un court-circuit est souhaité, voire nécessaire, mais votre scénario n'en fait pas partie.

Il est regrettable que contrairement à certains autres langages, Java n'ait pas &&=et ||=. Cela a été discuté dans la question Pourquoi Java n'a-t-il pas de versions d'assignation composée des opérateurs conditionnel et et conditionnel ou? (&& =, || =) .

Ce n'est pas un opérateur de "raccourci" (ou de court-circuit) de la façon dont || et && sont (en ce sens qu'ils n'évalueront pas le RHS s'ils connaissent déjà le résultat basé sur le LHS) mais il fera ce que vous voulez en termes de travail .

À titre d'exemple de la différence, ce code conviendra s'il textest nul:

boolean nullOrEmpty = text == null || text.equals("")

alors que ce ne sera pas:

boolean nullOrEmpty = false;
nullOrEmpty |= text == null;
nullOrEmpty |= text.equals(""); // Throws exception if text is null

(Évidemment, vous pouvez le faire "".equals(text)pour ce cas particulier - j'essaie simplement de démontrer le principe.)

Vous pourriez juste avoir une déclaration. Exprimé sur plusieurs lignes, il se lit presque exactement comme votre exemple de code, mais moins impératif:

boolean negativeValue
    = defaultStock < 0 
    | defaultWholesale < 0
    | defaultRetail < 0
    | defaultDelivery < 0;

Pour les expressions les plus simples, utiliser |peut être plus rapide que ||parce que même si cela évite de faire une comparaison, cela signifie utiliser une branche implicitement et cela peut être beaucoup plus cher.

Bien que cela puisse être excessif pour votre problème, la bibliothèque Guava a une bonne syntaxe avec Predicates et évalue en court-circuit ou / etPredicate s.

Essentiellement, les comparaisons sont transformées en objets, emballées dans une collection, puis répétées. Pour ou prédicats, le premier vrai hit revient de l'itération, et vice versa pour et.

S'il s'agit de lisibilité, j'ai le concept de séparation des données testées à partir de la logique de test. Exemple de code:

// declare data
DataType [] dataToTest = new DataType[] {
    defaultStock,
    defaultWholesale,
    defaultRetail,
    defaultDelivery
}

// define logic
boolean checkIfAnyNegative(DataType [] data) {
    boolean negativeValue = false;
    int i = 0;
    while (!negativeValue && i < data.length) {
        negativeValue = data[i++] < 0;
    }
    return negativeValue;
}

Le code semble plus détaillé et explicite. Vous pouvez même créer un tableau dans l'appel de méthode, comme ceci:

checkIfAnyNegative(new DataType[] {
    defaultStock,
    defaultWholesale,
    defaultRetail,
    defaultDelivery
});

Elle est plus lisible que la «chaîne de comparaison» et présente également un avantage en termes de performances de court-circuit (au prix de l'allocation de tableau et de l'appel de méthode).

Edit: Encore plus de lisibilité peut être simplement obtenue en utilisant les paramètres varargs:

La signature de la méthode serait:

boolean checkIfAnyNegative(DataType ... data)

Et l'appel pourrait ressembler à ceci:

checkIfAnyNegative( defaultStock, defaultWholesale, defaultRetail, defaultDelivery );

C'est un ancien post, mais afin de donner une perspective différente aux débutants, je voudrais donner un exemple.

Je pense que le cas d'utilisation le plus courant pour un opérateur composé similaire serait +=. Je suis sûr que nous avons tous écrit quelque chose comme ceci:

int a = 10;   // a = 10
a += 5;   // a = 15

Quel était le but de cela? Le but était d'éviter le passe-partout et d'éliminer le code répétitif.

Donc, la ligne suivante fait exactement la même chose, évitant de taper la variable b1deux fois dans la même ligne.

b1 |= b2;

List<Integer> params = Arrays.asList (defaultStock, defaultWholesale, 
                                       defaultRetail, defaultDelivery);
int minParam = Collections.min (params);
negativeValue = minParam < 0;

|| logique booléenne OU
| OU au niveau du bit

| = Opérateur OU et d'affectation inclusif au niveau du bit

La raison pour laquelle | = ne court-circuite pas est parce qu'il fait un OU au niveau du bit OU pas un OU logique. C'est-à-dire:

C | = 2 est identique à C = C | 2

Tutoriel pour les opérateurs Java