J'ai été ravi de l'utiliser pour la première fois récemment, c'est donc un mémo de l'exemple d'utilisation afin que je puisse l'utiliser à nouveau.
Je suis inscrit dans un domaine où Java 1.6 pourrait être forcé pour un tout nouveau projet en 2019. Je n'ai pas eu beaucoup d'occasions d'entrer en contact avec Java 8 pendant cette période. Dans de telles circonstances, je l'ai écrit avec les informations que j'ai entendues lorsque Java 8 est apparu, "Il semble que le contrôle nul puisse être facilement écrit à partir de Java 8." J'ai vérifié et écrit sur plusieurs sites, mais si vous avez des suggestions d'amélioration ou de Masakari, veuillez laisser un commentaire. (Parce qu'il n'y a pas de réviseur qui peut réviser mon code) (J'évalue d'autres membres)
get
Je ne l'utilise pas car je ne savais pas où l'utiliser.
Quand j'ai regardé certains sites, j'ai vu "Ne pas utiliser get
", donc je pense que c'était la bonne réponse. Il y a un sentiment.
"Facultatif peut simplement remplacer la vérification traditionnelle nulle" n'était pas la bonne perception. "Optionnel peut forcer une vérification nulle pour éliminer la possibilité d'oublier une vérification nulle" est correcte ... Ainsi, l'exemple de code fonctionne, mais il n'est pas écrit avec une reconnaissance correcte pour savoir comment utiliser Facultatif. Je laisserai cet article sans le supprimer pour ne pas l'oublier, mais veillez à ne pas vous faire prendre par quelqu'un comme moi qui est "facultatif pour la première fois!" Merci @sikani! Après tout, cela ne sert à rien si vous ne l'avez pas examiné par un expert ... Heureusement, j'étais mécontent de ne pas avoir mentionné l'écriture en option dans les critiques d'autres personnes. (Parce qu'il est important que le code de type Java 8 ne soit pas forcé)
Java 1.6 est écrit intentionnellement d'une manière étrange. Java 8 peut être écrit proprement: détendu: Pour Java8 ** C'est un peu faux à utiliser. ** ~~ Même avec Java 1.6, vous pouvez écrire dans une seule ligne avec un opérateur ternaire, mais ... ret est simplement inutile, si ~ else est utilisé sans même un retour anticipé, et la méthode privée n'est pas coupée, et si est écrite à chaque fois. La plupart du code hérité n'est pas vraiment cool, donc le refactoring me tue toujours. De plus, même si j'utilise Java 8, il y a trop de membres qui écrivent Java 1.6 tel quel, et je ris plus. J'ai des ennuis parce que je risque de me comprendre à tort comme un système hautement conscient ... Je me souviens de la récente controverse sur les rangs supérieurs. ~~ Je suis désolé de me plaindre.
Java1.6
public String toStringIfNotNull(final Object obj) {
String ret;
if (obj == null) {
ret = null;
} else {
ret = obj.toString();
}
return ret;
}
Java8
public String toStringIfNotNull(final Object obj) {
return Optional.ofNullable(obj).map(Object::toString).orElse(null);
}
Si vous utilisez Optional au lieu de null check, la combinaison de ʻof Nullable et ʻou Else
peut être la meilleure solution que ʻof`! ?? Impression.
S'il n'est pas nul et que la valeur d'origine est renvoyée telle quelle, s'agit-il d'une «carte» ou d'un traitement intermédiaire? Est tout simplement inutile.
En plus de map
, il y a filter
et flatMap
.
filter
renvoie l'argument de ʻorElses'il est nul et que le résultat du filtre est faux. Si
flatMap est nul, l'argument de ʻouElse
est renvoyé, mais si le résultat du traitement flatMap est nul, une exception NullPointerException est levée. (Dans le cas de map
, l'argument de ʻou Else` est retourné même si le résultat du traitement est nul)
Si vous voulez brancher le processus au lieu de renvoyer la valeur selon qu'elle est nulle ou non, vous pouvez écrire ʻif (Optional.ofNullable (obj) .isPresent ()) . De plus, ʻisPresent
ne renvoie qu'une valeur booléenne, mais si vous définissez ʻifPresentet passez une expression lambda comme argument, vous pouvez écrire que l'expression lambda de l'argument est exécutée uniquement lorsqu'elle n'est pas nulle. Eh bien, si c'est Java 7 ou une version ultérieure, je pense qu'il vaut mieux créer une branche avec ʻif (Objects.isNull (obj))
(nonNull) qu'avec isPresent.
J'ai remarqué que j'ai écrit jusqu'à présent, mais si c'est le contenu de traitement de l'exemple de code, ʻObjects.toString (obj, null) `(quelque chose comme StringUtils.defaultString) était bon ... je n'étais pas assez sûr.
Recommended Posts