Un nouveau champ booléen est-il préférable à une référence nulle lorsqu'une valeur peut être absente de manière significative?

Par exemple, supposons que j'ai une classe Member, qui a un lastChangePasswordTime:

class Member{
  .
  .
  .
  constructor(){
    this.lastChangePasswordTime=null,
  }
}

dont lastChangePasswordTime peut être absent de manière significative, car certains membres peuvent ne jamais changer leurs mots de passe.

Mais selon Si les valeurs nulles sont mauvaises, que faut-il utiliser lorsqu'une valeur peut être absente de manière significative? et https://softwareengineering.stackexchange.com/a/12836/248528 , je ne devrais pas utiliser null pour représenter une valeur significativement absente. Alors j'essaie d'ajouter un drapeau booléen:

class Member{
  .
  .
  .
  constructor(){
    this.isPasswordChanged=false,
    this.lastChangePasswordTime=null,
  }
}

Mais je pense que c'est assez obsolète parce que:

1. Lorsque isPasswordChanged a la valeur false, lastChangePasswordTime doit être null et la vérification de lastChangePasswordTime == null est presque identique à la vérification que isPasswordChanged est false, je préfère donc vérifier lastChangePasswordTime == null directement

2. En changeant la logique ici, je peux oublier de mettre à jour les deux champs.

Remarque: lorsqu'un utilisateur change de mot de passe, j'enregistre l'heure comme ceci:

this.lastChangePasswordTime=Date.now();

Le champ booléen supplémentaire est-il meilleur qu'une référence nulle ici?

Je ne vois pas pourquoi, si vous avez une valeur absente de manière significative, nullne devrait pas être utilisé si vous êtes délibéré et prudent à ce sujet.

Si votre objectif est d’entourer la valeur nullable afin d’éviter de la référencer accidentellement, nous vous suggérons de créer la isPasswordChangedvaleur en tant que fonction ou propriété renvoyant le résultat d’un contrôle nul, par exemple:

class Member {
    DateTime lastChangePasswordTime = null;
    bool isPasswordChanged() { return lastChangePasswordTime != null; }

}

À mon avis, le faire de cette façon:

• Donne une meilleure lisibilité du code qu'une vérification nulle, ce qui pourrait perdre du contexte.
• isPasswordChangedCela vous évite d'avoir à vous soucier de maintenir la valeur que vous mentionnez.

La façon dont vous conservez les données (probablement dans une base de données) serait responsable de la préservation des valeurs NULL.

nullsne sont pas mauvais. Les utiliser sans réfléchir est. C'est un cas où nullla réponse est exacte - il n'y a pas de date.

Notez que votre solution crée plus de problèmes. Quel est le sens de la date étant mise à quelque chose, mais le isPasswordChangedest faux? Vous venez de créer un cas d'informations conflictuelles que vous devez capturer et traiter spécialement, alors qu'une nullvaleur a un sens clairement défini et non ambigu et ne peut pas être en conflit avec d'autres informations.

Alors non, votre solution n'est pas meilleure. Permettre une nullvaleur est la bonne approche ici. Les gens qui prétendent que nullc'est toujours mauvais, peu importe le contexte, ne comprennent pas pourquoi nullexiste.

Selon votre langage de programmation, il peut exister de bonnes alternatives, telles qu'un optionaltype de données. En C ++ (17), ce serait std :: optional . Il peut être absent ou avoir une valeur arbitraire du type de données sous-jacent.

Utiliser correctement null

Il y a différentes façons d'utiliser null. La manière la plus courante et sémantiquement correcte consiste à l'utiliser lorsque vous pouvez avoir ou non une valeur unique . Dans ce cas, une valeur est égale nullou significative (par exemple, un enregistrement de base de données).

Dans ces situations, vous l'utilisez principalement comme ceci (en pseudo-code):

if (value is null) {
  doSomethingAboutIt();
  return;
}

doSomethingUseful(value);

Problème

Et c'est un très gros problème. Le problème est qu’au moment où vous appelez, doSomethingUsefulla valeur n’a peut-être pas été vérifiée null! Si ce n'était pas le cas, le programme va probablement planter. Et l'utilisateur peut même ne pas voir de bons messages d'erreur, laissant quelque chose comme "une erreur horrible: valeur recherchée mais nulle"! " (après la mise à jour: bien qu'il puisse y avoir encore moins d'erreur informative comme Segmentation fault. Core dumped., ou pire encore, aucune erreur et une manipulation incorrecte sur null dans certains cas)

Oublier d'écrire des chèques nullet de gérer des nullsituations est un bogue extrêmement courant . Voilà pourquoi Tony Hoare qui a inventé nulllors d' une conférence de logiciel appelé QCon Londres en 2009 qu'en 1965 , il a fait l'erreur d'un milliard de dollars: https://www.infoq.com/presentations/Null-References-The-Billion-Dollar- Erreur-Tony-Hoare

Éviter le problème

Certaines technologies et langues rendent la vérification nullimpossible à oublier de différentes manières, réduisant ainsi le nombre de bugs.

Par exemple, Haskell a la Maybemonade au lieu de NULL. Supposons qu'il s'agisse d' DatabaseRecordun type défini par l'utilisateur. Dans Haskell, une valeur de type Maybe DatabaseRecordpeut être égale Just <somevalue>ou égale à Nothing. Vous pouvez ensuite l'utiliser de différentes manières, mais vous ne pouvez pas appliquer une opération Nothingsans le savoir, peu importe la façon dont vous l'utilisez .

Par exemple, cette fonction appelée zeroAsDefaultrenvoie xpour Just xet 0pour Nothing:

zeroAsDefault :: Maybe Int -> Int
zeroAsDefault mx = case mx of
    Nothing -> 0
    Just x -> x

Christian Hackl dit que C ++ 17 et Scala ont leurs propres méthodes. Donc, vous voudrez peut-être essayer de savoir si votre langue a quelque chose comme ça et l'utiliser.

Les null sont encore largement utilisés

Si vous n'avez rien de mieux à utiliser, alors nullc'est bien. Continuez juste à le surveiller. Les déclarations de type dans les fonctions vous aideront quand même un peu.

En outre, cela peut sembler peu progressif, mais vous devriez vérifier si vos collègues veulent utiliser nullquelque chose d’autre. Ils peuvent être conservateurs et ne pas vouloir utiliser de nouvelles structures de données pour certaines raisons. Par exemple, supporter les anciennes versions d'une langue. Ces éléments doivent être déclarés dans les normes de codage du projet et dûment discutés avec l'équipe.

Sur votre proposition

Vous suggérez d'utiliser un champ booléen séparé. Mais vous devez quand même le vérifier et vous pouvez toujours oublier de le vérifier. Donc, il n'y a rien gagné ici. Si vous pouvez même oublier autre chose, comme mettre à jour les deux valeurs à chaque fois, c'est encore pire. Si le problème de l’oubli de la vérification nulln’est pas résolu, cela ne sert à rien. Éviter nullest difficile et vous ne devriez pas le faire de manière à aggraver les choses.

Comment ne pas utiliser null

Enfin, il existe des moyens courants d'utiliser de nullmanière incorrecte. L’un de ces moyens consiste à l’utiliser à la place de structures de données vides telles que des tableaux et des chaînes. Un tableau vide est un tableau approprié comme un autre! Il est presque toujours important et utile que les structures de données, qui peuvent contenir plusieurs valeurs, puissent être vides, c'est-à-dire qu'elles ont une longueur égale à 0.

Du point de vue de l'algèbre, une chaîne vide pour les chaînes ressemble beaucoup à 0 pour les nombres, c'est-à-dire l'identité:

a+0=a
concat(str, '')=str

Une chaîne vide permet aux chaînes de devenir en général un monoïde: https://en.wikipedia.org/wiki/Monoid Si vous ne l'obtenez pas, ce n'est pas si important pour vous.

Voyons maintenant pourquoi il est important de programmer avec cet exemple:

for (element in array) {
  doSomething(element);
}

Si nous passons ici un tableau vide, le code fonctionnera correctement. Cela ne fera que rien. Cependant, si nous passons un nullici, nous aurons probablement un crash avec une erreur du type "impossible de parcourir en boucle null, désolé". Nous pourrions l'envelopper ifmais c'est moins propre et encore une fois, vous pourriez oublier de vérifier

Comment gérer null

Ce qui doSomethingAboutIt()devrait être fait et surtout s’il faut lever une exception est une autre question compliquée. En bref, cela dépend de la question de savoir si nullétait une valeur d'entrée acceptable pour une tâche donnée et ce qui est attendu en réponse. Les exceptions concernent des événements inattendus. Je n'irai pas plus loin dans ce sujet. Cette réponse est déjà très longue.

En plus de toutes les très bonnes réponses données précédemment, j'ajouterais que chaque fois que vous êtes tenté de laisser un champ nul, réfléchissez bien s'il peut s'agir d'un type de liste. Un type nullable est équivalent à une liste de 0 ou 1 éléments, ce qui peut souvent être généralisé à une liste de N éléments. Plus précisément dans ce cas, vous pouvez envisager de lastChangePasswordTimeconstituer une liste de passwordChangeTimes.

Posez-vous la question suivante: quel comportement requiert le champ lastChangePasswordTime?

Si vous avez besoin de ce champ pour une méthode IsPasswordExpired () afin de déterminer si un membre doit être invité à changer son mot de passe de temps en temps, je définirais le champ à la date à laquelle le membre a été créé. L'implémentation IsPasswordExpired () est la même pour les membres nouveaux et existants.

class Member{
   private DateTime lastChangePasswordTime;

   public Member(DateTime lastChangePasswordTime) {
      // set value, maybe check for null
   }

   public bool IsPasswordExpired() {
      DateTime limit = DateTime.Now.AddMonths(-3);
      return lastChangePasswordTime < limit;
   }
}

Si vous avez une exigence distincte que les membres nouvellement créés doivent mettre à jour leur mot de passe, je voudrais ajouter un champ booléen appelé séparés passwordShouldBeChanged et à true lors de la création. Je voudrais ensuite changer les fonctionnalités de la méthode IsPasswordExpired () pour inclure une vérification de ce champ (et renommer la méthode en ShouldChangePassword).

class Member{
   private DateTime lastChangePasswordTime;
   private bool passwordShouldBeChanged;

   public Member(DateTime lastChangePasswordTime, bool passwordShouldBeChanged) {
      // set values, maybe check for nulls
   }

   public bool ShouldChangePassword() {
      return PasswordExpired(lastChangePasswordTime) || passwordShouldBeChanged;
   }

   private static bool PasswordExpired(DateTime lastChangePasswordTime) {
      DateTime limit = DateTime.Now.AddMonths(-3);
      return lastChangePasswordTime < limit;
   }
}

Rendez vos intentions explicites dans le code.

Tout d’abord, le fait que le mal soit nul est un dogme et, comme d’habitude avec un dogme, il fonctionne mieux comme ligne directrice que comme test de réussite ou non.

Deuxièmement, vous pouvez redéfinir votre situation de manière à ce que la valeur ne puisse jamais être nulle. InititialPasswordChanged est un booléen initialement défini sur false, PasswordSetTime est la date et l'heure auxquelles le mot de passe actuel a été défini.

Notez que bien que cela vienne à un léger coût, vous pouvez maintenant TOUJOURS calculer le temps écoulé depuis la dernière définition d’un mot de passe.

Les deux sont «sûrs / sains / corrects» si l'appelant vérifie avant l'utilisation. Le problème est ce qui se passe si l'appelant ne vérifie pas. Quel est le meilleur, une sorte d'erreur de null ou d'utiliser une valeur invalide?

Il n'y a pas une seule bonne réponse. Cela dépend de ce qui vous inquiète.

Si les plantages sont vraiment graves mais que la réponse n'est pas critique ou a une valeur par défaut acceptée, il est peut-être préférable d'utiliser un booléen comme indicateur. Si utiliser la mauvaise réponse est un problème pire que de planter, utiliser null est préférable.

Pour la majorité des cas "typiques", un échec rapide et le fait de forcer les appelants à vérifier est le moyen le plus rapide d'obtenir du code sain d'esprit, et par conséquent, je pense que null devrait être le choix par défaut. Je ne mettrais pas trop de foi dans le "X est la racine de tout le mal" évangélistes cependant; ils n'ont normalement pas anticipé tous les cas d'utilisation.