Des expressions booléennes en Java
J'ai une question à propos de la signification (évaluation) de variables Booléennes en retour des déclarations en Java.
Je sais que:
if (var) { ... }
est la même chose que:
if (var==true) { ... }
Dans le second cas nous indiquent explicitement var==vrai, mais nous n'avons pas besoin de le faire, parce que Java évalue la var comme vrai de toute façon. J'espère que j'ai bien compris ce droit.
Ma question est: est-il le même lorsque les variables Booléennes sont-ils de retour? Lorsque nous avons une instruction de retour?
Par exemple, une tâche précise: la méthode looksBetter() retournera true seulement si b < un. Ma solution a été:
public boolean looksBetter() {
if (b < a) {
return true;
} else {
return false;
}
}
La réponse était simple:
public boolean lookBetter() {
return b < a;
}
Donc, il semble que nous avons ici encore une fois cette hypothèse implicite que dans le cas b < a == true, le retour de la méthode est vrai.
Je suis désolé ... il semble très banal, mais je suis en quelque sorte pas à l'aise avec cela, et je ne sais pas pourquoi. Merci.
OriginalL'auteur user42155 | 2009-01-29
Vous devez vous connecter pour publier un commentaire.
Ce n'est pas une "hypothèse implicite," c'est ce que le compilateur fait. Le
b < a
est juste une expression, le même que s'il était utilisé pour unif
déclaration. L'expression est évaluée à unboolean
, qui est ensuite retourné.Également intéressant de noter, vous semblez échange
boolean
etBoolean
comme s'ils sont les mêmes, mais ils ne sont pas vraiment.boolean
est le primitive forme tout enBoolean
est un Objet qui encapsule uneboolean
.Je suis d'accord sur un point, mais il y a certainement une différence entre eux qui doivent être compris, surtout pour quelqu'un de nouveau à la langue.
La seule chose à corriger avec le "essentiellement la même chose" approche est l'utilisation de null. Les objets peuvent être null, primitives peuvent pas. Essayez d'auto-unboxing une valeur null. Pas exactement évident que l'exception signifie.
"primitives et de l'objet des wrappers sont la même chose".
boolean
peut être vrai ou faux, toutBoolean
peut également être null.OriginalL'auteur Rob Hruska
Oui, cela est vrai pour toutes les valeurs booléennes. Vous pouvez penser si(expression) l'évaluation de "l'expression" pour voir si elle est 'true' ou 'false'. Lorsque vous ne
d'abord des tests pour voir si le b < a, et si elle l'est, c'tests:
Maintenant teste si true == true (ce qui ne veut évidemment). Java n'est pas de faire quelque chose de difficile quand vous quittez l'extra "= = true", il a juste besoin d'effectuer moins un test. Il n'y a aucune raison que vous ne pouvait pas dire:
mais il serait la cause de Java pour effectuer un test supplémentaire chaque fois qu'il voit un signe d'égalité.
OriginalL'auteur Bill Zeller
Ne pas compliquer inutilement votre code. Si vous vous sentez le besoin de dire "a < b == true", alors vous pouvez suivre à sa logique conflusion (conclusion + confusion) et de dire "
((((((((...(a<b) == true) == true).... == true)
""a < b" est une expression booléenne. Si vous avez déjà un booléen, pourquoi le comparer à un autre boolean? Vous n'êtes pas rendre plus booléenne de cette façon.
OriginalL'auteur Paul Tomblin
Java conditionnelle nécessite une valeur booléenne. Si vous pouvez le mettre dans une instruction if, c'est déjà un booléen, et ne nécessite aucune autre tripoter si ce que vous voulez est un booléen.
En effet, des constructions comme les
value == true
peut être délicat. Je n'ai pas désinvolte, rappelez-vous les règles de la promotion en Java, mais en C++ un booléen peut être promu à un int, avec de faux devient 0 et true devenir 1. Par conséquent,int a = 2; if (a)
etint a = 2; if (a == true)
va faire des choses différentes.OriginalL'auteur David Thornley
Votre confusion peut être facile si vous essayez de penser à des opérateurs de méthodes. À l'aide de votre exemple, vous avez eu la < "moins" de l'opérateur. Pour nos fins, les < opérateur peut vraiment être considéré comme une "méthode" (il ne ne ressemble pas à un seul), qui prend deux paramètres et renvoie une valeur booléenne. Si la "méthode" ont été nommés lessThan, votre exemple serait équivalent à ceci:
Peut-être voir ça comme ça la rend un peu plus facile à comprendre? D'ailleurs, quand j'étais à la tête de groupes d'exercice dans la "Programmation 101' parcours de retour à l'Uni, cela s'est avéré être de loin la chose la plus difficile à enseigner, et beaucoup de gens avaient du mal à saisir les concepts impliqués. Il semblait presque être apparenté à apprendre à faire du vélo ou de la natation, une fois que vous obtenez comment cela fonctionne, il devient évident.
OriginalL'auteur Emil Fors
Comme C++ tout énoncé a une valeur de retour, même les choses sur le côté gauche de l'opérateur. Certains des plus fou C++ que j'ai vu a opérations sur le côté gauche, en plus de leur être attribué.
Je trouve cela fonctionne le mieux si je ne les suivants:
La seule raison d'être que s'en est un peu plus facile à déboguer (dans n'importe quel IDE). Je trouve que j'ai toujours l'envelopper dans de la parenthèse, je ne suis pas tout à fait sûr pourquoi. Je pense qu'il conserve la variable électrons chauds pendant leur sommeil dans la nuit.
OriginalL'auteur slf
Je pense que vous me demandez pourquoi vous rencontrez un problème conceptuel.
Je pense que le problème de base est que lorsque vous directement renvoyer une valeur booléenne, il vous manque quelque chose, et vous l'êtes. C'est le nom de la méthode dans votre cas.
Votre LooksBetter ne signifie rien. Ce que vous êtes vraiment la pensée est: est-ce
Maintenant, vous pouvez réduire à:
Hmm, eh bien maintenant, nous pouvons voir que l'une est antérieure à celle de b et qu'est ce que la valeur intermédiaire isEarlier moyens.
Donc, une fois que vous internaliser que la valeur intermédiaire, cela fait plus de sens:
Que vous avez à penser que "Boolean" comme une valeur réelle, et pas seulement certains d'état intermédiaire. Si cela vous rend mal à l'aise, n'hésitez pas à faire une variable (il n'a vraiment rien coûté, et peut le rendre plus lisible pour vous pour l'instant).
Plus tard, vous allez regarder en arrière sur votre code et être plus à l'aise avec la façon plus simple de le regarder. Surtout prend du temps pour votre esprit de se développer certaines de nouveaux chemins, de ne pas être gêné d'être explicite dans l'intervalle.
OriginalL'auteur Bill K
Ce n'est pas une "hypothèse implicite", ou quelque autre sorte de magie.
Seulement deux d'une expression différente qui donnent le même résultat.
C'est quelque chose comme
ou
"i" et "i+0" sont deux expression que les résultats de la même valeur. (Le compilateur doit être assez intelligent pour simplifier la dernière dans la même que la première)
OriginalL'auteur Carlos Heuberger
Votre méthode de travail, mais il peut être un peu difficile de ce exactement devrait se produire, en particulier si vous avez des variables nommées a et b. Vous souhaitez documenter la méthode et ont des variables avec des noms propres.
Aussi, si le code est source de confusion pour vous juste après que vous avez écrit-il, de penser à quelqu'un qui va venir dans les 6 mois et ne pas avoir la moindre idée de ce qui se passe. Une bonne documentation et des commentaires aidera grandement.
OriginalL'auteur Tai Squared