mybatis3中PerpetualCache中的equals和hashCode方法在第一行先判断getId() == null, 有点不能理解， 为什么要这个判断， 不是不可能为null吗。
代码如下：
@Override
public boolean equals(Object o) {
if (getId() == null) {
throw new CacheException("Cache instances require an ID.");
}
if (this == o) {
return true;
}
if (!(o instanceof Cache)) {
return false;
}
Cache otherCache = (Cache) o;
return getId().equals(otherCache.getId());
}
@Override
public int hashCode() {
if (getId() == null) {
throw new CacheException("Cache instances require an ID.");
}
return getId().hashCode();
}
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
La méthode du framework sous-jacent ne peut pas connaître toute l'utilisation de la couche application. Il est très probable que certaines personnes ne suivent pas les règles. Afin de garantir l'exactitude du programme, il est nécessaire de créer du code défensif.
id détermine l'unicité du cache, hashCode, méthode égale pour déterminer la référence d'unicité
C'est une bonne habitude de programmation
Lorsque vous travaillez en collaboration, vous ne pouvez pas juger l'appelant. Notre accord verbal peut facilement être rompu par quelqu'un. Afin d'éviter que quelqu'un ne fasse une telle chose, la vérification des paramètres est un comportement très significatif et nécessaire, ce qui facilite également le dépannage.
Pas mal, j'ai beaucoup appris
Et si getId()==null, vous avez inversé la cause et le résultat, car il n'est pas autorisé à être nul, il y a donc un jugement if. S'il est nul, une exception personnalisée est levée pour vous le dire. ça ne peut pas être nul
C'est la mise en œuvre de la stratégie de DBC
Il existe trois types de DBC :
1.Post-conditions La postcondition représente le résultat qui sera définitivement obtenu en appelant une méthode. Comme pour les assertions, si le langage ne prend pas en charge les assertions, nous devons alors écrire nous-mêmes des assertions, qui sont pilotées par des tests.
2.Pre-conditions préalables, qui garantissent à l'avance que la post-condition doit répondre à la pré-condition.
Les conditions préalables doivent être remplies et les postconditions doivent être réalisées. Grâce à la combinaison des conditions préalables et postconditions du contrat, il n'y aura pas d'obligations fonctionnelles cachées, de sorte que les choses soient clairement définies. Ce n'est qu'ainsi que la conception pourra être implémentée dans le code pour garantir des appels d'objet normaux.
3. Invariant de classe L'invariant de classe représente l'affirmation de l'état de l'objet, qui doit être satisfait après avoir effectué toute opération. L'invariant définit toujours strictement l'intégrité de l'agrégat.