Le système de types de Java ne le prend pas en charge et ne peut être implémenté que via des plug-ins : Checker Framework Pour ajouter des annotations, spécifiez le plug-in lors de la compilation.
Ce qui précède implémente la détection de null par le compilateur. Quant au crash si null est passé, cela peut être réalisé en insérant un code de vérification null via un plug-in.
Bonne question. Je me concentre généralement uniquement sur la façon d'implémenter les fonctions, mais je n'ai pas beaucoup réfléchi aux raisons pour lesquelles Java ne les implémente pas de cette façon, comme cette question. Cela a également suscité beaucoup d'imagination en moi. Ce serait formidable si la syntaxe Java était prise en charge, l'efficacité du développement serait au moins plusieurs fois supérieure, mais quand j'y repense, quelque chose ne va pas.
Il y a une certaine raison pour laquelle NullPointerException est une exception d'exécution
En supposant que Java prenne en charge une telle syntaxe, utilisez l'annotation : @NotNullIndiquez que le paramètre n'est pas vide
Un scénario comme celui-ci : une fois que l'utilisateur s'est connecté avec succès, l'heure de connexion et l'adresse IP de l'utilisateur sont mises à jour.
Les données utilisateur comprennent :
name
password
lasttime
ip
aaa
123456
2017-01-09
192.168.1.1
bbb
123456
2017-01-08
192.168.1.1
Mettre à jour le pseudo-code des informations utilisateur :
public void updateAccount(@NotNull Account account) {
// 因为肯定不为空,可以放心大胆的更新Account的最新登录时间、ip
}
@NotNull indique des paramètres : account ne peut pas être vide, il n'y a pas de problème ici.
Obtenir le pseudo-code de connexion de vérification des informations utilisateur :
Nous ne voulons tout simplement pas que les paramètres soient vides, et nous ne voulons pas que la valeur de retour soit vide, donc il n'y a pas de problème.
Alors la question est la suivante : le paramètre de compte peut-il être transmis à la méthode service.updateAccount() et la compilation peut-elle réussir ? L'objet Accoount lu dans la base de données est intrinsèquement un objet ambigu. Il peut représenter une certaine personne ou il peut s'agir de null.
Alors rendre la valeur de retour non nulle ?
Oui, cela peut être comme ça. Cela devient un modèle appelé NullObject Pattern (NullObject Pattern) , ce qui signifie créer un objet vide dédié pour représenter que le résultat est vide.
Le système de types de Java ne le prend pas en charge et ne peut être implémenté que via des plug-ins : Checker Framework Pour ajouter des annotations, spécifiez le plug-in lors de la compilation.
Ce qui précède implémente la détection de null par le compilateur. Quant au crash si null est passé, cela peut être réalisé en insérant un code de vérification null via un plug-in.
Bonne question. Je me concentre généralement uniquement sur la façon d'implémenter les fonctions, mais je n'ai pas beaucoup réfléchi aux raisons pour lesquelles Java ne les implémente pas de cette façon, comme cette question. Cela a également suscité beaucoup d'imagination en moi. Ce serait formidable si la syntaxe Java était prise en charge, l'efficacité du développement serait au moins plusieurs fois supérieure, mais quand j'y repense, quelque chose ne va pas.
Il y a une certaine raison pour laquelle NullPointerException est une exception d'exécution
En supposant que Java prenne en charge une telle syntaxe, utilisez l'annotation :
@NotNull
Indiquez que le paramètre n'est pas videUn scénario comme celui-ci : une fois que l'utilisateur s'est connecté avec succès, l'heure de connexion et l'adresse IP de l'utilisateur sont mises à jour.
Les données utilisateur comprennent :
Mettre à jour le pseudo-code des informations utilisateur :
@NotNull
indique des paramètres :account
ne peut pas être vide, il n'y a pas de problème ici.Obtenir le pseudo-code de connexion de vérification des informations utilisateur :
Nous ne voulons tout simplement pas que les paramètres soient vides, et nous ne voulons pas que la valeur de retour soit vide, donc il n'y a pas de problème.
Pseudo-code du jugement logique principal :
Alors la question est la suivante : le paramètre de compte peut-il être transmis à la méthode
service.updateAccount()
et la compilation peut-elle réussir ? L'objetAccoount
lu dans la base de données est intrinsèquement un objet ambigu. Il peut représenter une certaine personne ou il peut s'agir denull
.Alors rendre la valeur de retour non nulle ?
Oui, cela peut être comme ça. Cela devient un modèle appelé NullObject Pattern (NullObject Pattern) , ce qui signifie créer un objet vide dédié pour représenter que le résultat est vide.
Veuillez vérifier les détails :
https://segmentfault.com/q/10...
http://www.cnblogs.com/haodaw...