[JAVA] types et idéaux nuls et facultatifs et réalité

Récemment, j'ai commencé à développer des applications mobiles et j'ai commencé à étudier swift et kotlin. Dans de telles circonstances, j'ai d'abord abordé le concept de "type facultatif" et je me suis demandé "y a-t-il un langage qui a un type aussi pratique?", Mais après un examen attentif, j'ai trouvé que Java 8 a également le type facultatif. Je le savais maintenant. Ce qui suit est JavaDoc sur facultatif. https://docs.oracle.com/javase/jp/8/docs/api/java/util/Optional.html

Qu'est-ce que le type facultatif?

Un type de variable qui peut stocker null ( nil dans certaines langues). En Java, les ** types primitifs ** tels que ʻintetboolean ne peuvent pas stocker null (erreur de compilation), mais les ** variables de type référence ** telles que ʻInteger et String sont Puisque null peut être stocké, une exception NullPointerException peut se produire si vous ne cochez pas null à l'avance.

Avantages du type facultatif

La première question que j'ai ressentie en tant que débutant du programme.

Puisque le type de référence est également inclus dans null, il n'y a pas besoin de se soucier de définir le type ʻOptional`, non?

Certes, dans le sens de "un type qui peut être" nul "", ni le type facultatif ni le type référence ne sont pertinents. L'important est que dans le cas du type référence, il faut cocher «null», et il est facile de le négliger. Si vous négligez de cocher null, vous obtiendrez une NullPointerException, mais comme il s'agit d'une exception d'exécution, dans le pire des cas, vous ne remarquerez peut-être pas qu'il ne s'agira pas d'un échec de production.

String str = getString();//Si cela renvoie null
//Si vous oubliez l'instruction if suivante, elle se compilera, mais vous obtiendrez une exception NullPointerException au moment de l'exécution.
//if(str == null){
//    str = "";
//}
return str.length();

D'autre part, lorsque le type Facultatif est utilisé, la valeur ne peut pas être récupérée à moins qu'une méthode dédiée ne soit utilisée, donc ** doit être codé en tenant compte du cas de «null». ** ** En d'autres termes, je pense que le plus grand mérite est que vous n'oublierez pas quoi faire si «null» entre involontairement.

Optional<String> opt = Optional.ofNullable(getString());
String str = opt.orElse(""); //Pour récupérer une valeur de Optional, une méthode qui considère null`orElse`Il ne peut pas être retiré sans utilisation.
return str.length();

Mais à l'origine, nous devrions éliminer les valeurs nulles inattendues

Pourquoi. J'ai complètement oublié ces jours-ci, mais il n'est pas important de m'assurer que tout va bien si quelque chose d'inattendu se produit (cochez null), et il n'est pas important de faire quelque chose d'inattendu. Il est plus important de ne pas le faire (éliminer la cause du retour de «null»).

Si vous le comparez avec le code ci-dessus,

String str = getString();//N'est-il pas mauvais pour getString de renvoyer null en premier lieu?
//Le processus suivant aurait dû être décrit, mais getString()N'est pas répertorié dans les spécifications pour renvoyer null
//if(str == null){
//    str = "";
//}
return str.length();

Tel est le cas. N'est-il pas simple de penser qu'il est prudent de vérifier "null" pour le moment, sans savoir qui (quel code) est responsable de considérer "null"?

Par expérience, le module correspondant au précédent getString est un module prérequis réalisé il y a longtemps par un autre fournisseur, ou il est également détourné vers d'autres systèmes qui sont déjà en fonctionnement, donc il est lié au coût de maintenance du projet sous contrat etc. Pour cette raison, il est souvent traité comme un "module qui ne peut pas être réparé", et il est massivement codé en fonction de la situation selon laquelle "il n'y a pas d'autre choix que de penser de manière réaliste" plutôt que l'idée que "cela devrait être comme une conception". Il y a beaucoup de.

La raison pour laquelle j'ai décidé de rédiger cet article est que je suis satisfait du fait que je n'ai pas d'autre choix que de penser de manière réaliste récemment, et je vais l'implémenter simplement en pensant qu'il est prudent de vérifier `null 'pour le moment. Parce que j'avais l'impression que c'était devenu.

Il est bien connu que le module n'a pas été initialement rendu "null", mais a été laissé comme une implémentation dans laquelle "null" a été entré par inadvertance par le programmeur, et qu'il a été intentionnellement rendu "nul". Le fait de juger qu '"il est impossible de devenir" nul "dans ce cas" est mauvais car l'héritage du contenu "rendu intentionnellement" nul "" est interrompu sans ou avec le temps.

Résumé

Le type facultatif peut forcer le programmeur à considérer le cas de «null», mais l'idée de concevoir comment gérer «null» ne doit pas être oubliée. (← Commandements à vous-même)

Par exemple, si getString () est un module qui peut retourner null, la valeur de retour de getString () doit également être facultative.

Optional<String> opt = getString();//Doit être explicitement indiqué pour renvoyer un type facultatif
String str = opt.orElse("");
return str.length();

Alternativement, s'il doit être garanti que getString () ne renvoie pas null, alors le traitement interne getString () peut être modifié de sorte que l'appelant n'utilise pas le type facultatif.

String str = getString();//S'il est garanti qu'il est absolument non nul
//L'instruction if suivante sera du code mort, il est donc correct de ne pas l'implémenter
//if(str == null){
//    str = "";
//}
return str.length();

Même dans les nouveaux langages comme swift et kotlin qui peuvent utiliser Optional, cette idée ne doit pas être oubliée.