Является ли новое булево поле лучше нулевой ссылки, когда значение может отсутствовать?

Например, предположим, у меня есть класс Member, который имеет lastChangePasswordTime:

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

у которого lastChangePasswordTime может отсутствовать, потому что некоторые участники никогда не могут менять свои пароли.

Но в соответствии с тем, что пустые значения являются злом, что следует использовать, когда значение может отсутствовать по значению? и https://softwareengineering.stackexchange.com/a/12836/248528 , я не должен использовать null для представления значимо отсутствующего значения. Поэтому я пытаюсь добавить логический флаг:

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

Но я думаю, что это довольно устарело, потому что:

1. Когда isPasswordChanged имеет значение false, lastChangePasswordTime должно иметь значение null, а проверка lastChangePasswordTime == null практически идентична проверке isPasswordChanged - false, поэтому я предпочитаю проверить lastChangePasswordTime == null напрямую

2. При изменении логики здесь я могу забыть обновить оба поля.

Примечание: когда пользователь меняет пароли, я записываю время следующим образом:

this.lastChangePasswordTime=Date.now();

Является ли дополнительное булево поле лучше нулевой ссылки здесь?

Я не понимаю, почему, если у вас есть значимое отсутствие значения, nullего не следует использовать, если вы намеренно и осторожно относитесь к нему.

Если ваша цель заключается в том, чтобы заключить значение Nullable во избежание случайного обращения к нему, я бы предложил создать isPasswordChangedзначение в виде функции или свойства, которое возвращает результат нулевой проверки, например:

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

}

На мой взгляд, делать это так:

• Дает лучшую читаемость кода, чем нулевая проверка, которая может потерять контекст.
• Устраняет необходимость беспокоиться о сохранении упомянутой isPasswordChangedвами ценности.

То, как вы сохраняете данные (предположительно в базе данных), будет отвечать за сохранение нулей.

nullsне злые Использование их без размышлений есть. Это тот случай, когда nullточно правильный ответ - даты нет.

Обратите внимание, что ваше решение создает больше проблем. Что означает дата, установленная для чего-то, но isPasswordChangedложная? Вы только что создали случай противоречивой информации, которую нужно специально отловить и обработать, в то время как nullзначение имеет четко определенное, однозначное значение и не может противоречить другой информации.

Так что нет, ваше решение не лучше. Принятие nullзначения является правильным подходом здесь. Люди, которые утверждают, что nullэто всегда зло, независимо от контекста, не понимают, почему nullсуществует.

В зависимости от вашего языка программирования, могут быть хорошие альтернативы, такие как optionalтип данных. В C ++ (17) это будет std :: необязательный . Он может отсутствовать или иметь произвольное значение базового типа данных.

Правильно используя нуль

Есть разные способы использования null. Наиболее распространенный и семантически правильный способ - использовать его, когда вы можете иметь или не иметь единственное значение. В этом случае значение либо равно, nullлибо является чем-то значимым, например запись из базы данных или что-то еще.

В этих ситуациях вы в основном используете это так (в псевдокоде):

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

doSomethingUseful(value);

проблема

И это очень большая проблема. Проблема в том, что к тому времени, когда вы вызываете doSomethingUsefulзначение, возможно, не было проверено null! Если этого не произошло, программа, скорее всего, вылетит. И пользователь может даже не увидеть никаких хороших сообщений об ошибках, оставаясь с чем-то вроде «ужасная ошибка: хотел значение, но получил ноль!» (после обновления: хотя может быть даже менее информативная ошибка, например Segmentation fault. Core dumped., или, что еще хуже, в некоторых случаях нет ошибок и неправильных манипуляций с нулем)

Забыть писать чеки nullи обрабатывать nullситуации - очень распространенная ошибка . Вот почему изобретатель Тони Хоар nullсказал на конференции по программному обеспечению QCon London в 2009 году, что он допустил ошибку в миллиард долларов в 1965 году: https://www.infoq.com/presentations/Null-References-The-Billion-Dollar- Ошибка-Тони Хоара

Как избежать проблемы

Некоторые технологии и языки делают проверку на nullневозможность забыть по-разному, уменьшая количество ошибок.

Например, Haskell имеет Maybeмонаду вместо нулей. Предположим, что DatabaseRecordэто определенный пользователем тип. В Haskell значение типа Maybe DatabaseRecordможет быть равным Just <somevalue>или равным Nothing. Затем вы можете использовать его по-разному, но независимо от того, как вы его используете, вы не сможете применить некоторые операции, Nothingне зная об этом.

Например, эта вызываемая функция zeroAsDefaultвозвращает xдля Just xи 0для Nothing:

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

Кристиан Хакл говорит, что C ++ 17 и Scala имеют свои собственные пути. Поэтому вы можете попытаться выяснить, есть ли на вашем языке что-то подобное, и использовать его.

Нули все еще широко используются

Если у вас нет ничего лучше, тогда nullпользуйтесь. Просто продолжайте следить за этим. Объявления типов в функциях помогут вам в любом случае.

Также это может звучать не очень прогрессивно, но вы должны проверить, хотят ли ваши коллеги использовать nullили что-то еще. Они могут быть консервативными и могут не хотеть использовать новые структуры данных по некоторым причинам. Например, поддержка старых версий языка. Такие вещи должны быть заявлены в стандартах кодирования проекта и должным образом обсуждены с командой.

По вашему предложению

Вы предлагаете использовать отдельное логическое поле. Но вы все равно должны это проверить и все же можете забыть это проверить. Так что здесь ничего не выиграно. Если вы даже можете забыть что-то еще, например, каждый раз обновлять оба значения, то это еще хуже. Если проблема забвения чека nullне решена, тогда нет смысла. Избегать nullтрудно, и вы не должны делать это таким образом, чтобы это еще хуже.

Как не использовать нуль

Наконец, есть общие способы использования nullнеправильно. Один из таких способов - использовать его вместо пустых структур данных, таких как массивы и строки. Пустой массив - это правильный массив, как и любой другой! Почти всегда важно и полезно, чтобы структуры данных, которые могут соответствовать нескольким значениям, могли быть пустыми, то есть иметь длину 0.

С точки зрения алгебры пустая строка для строк очень похожа на 0 для чисел, то есть тождество:

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

Пустая строка позволяет строкам в целом стать моноидом: https://en.wikipedia.org/wiki/Monoid Если вы его не получите, это не так важно для вас.

Теперь давайте посмотрим, почему это важно для программирования на следующем примере:

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

Если мы передадим пустой массив здесь, код будет работать нормально. Это просто ничего не сделает. Однако, если мы передадим nullздесь, то, скорее всего, получим сбой с ошибкой типа «не могу пройти через ноль, извините». Мы могли бы обернуть это, ifно это не так чисто, и опять же, вы можете забыть проверить это

Как обращаться с нулем

Что doSomethingAboutIt()следует делать, и особенно то, должно ли оно генерировать исключение, это еще один сложный вопрос. Короче говоря, это зависит от того, nullбыло ли приемлемое входное значение для данной задачи и что ожидается в ответ. Исключения составляют события, которые не были ожидаемы. Я не буду углубляться в эту тему. Этот ответ очень длинен уже.

В дополнение ко всем очень хорошим ответам, которые были даны ранее, я бы добавил, что каждый раз, когда у вас возникает желание оставить поле пустым, тщательно подумайте, может ли это быть тип списка. Обнуляемый тип эквивалентен списку из 0 или 1 элементов, и часто его можно обобщить до списка из N элементов. В этом случае, возможно, вы захотите рассмотреть lastChangePasswordTimeсписок passwordChangeTimes.

Задайте себе вопрос: какое поведение требует поле lastChangePasswordTime?

Если вам нужно это поле для метода IsPasswordExpired (), чтобы определить, нужно ли участнику запрашивать смену пароля так часто, я бы установил в поле время, когда он был изначально создан. Реализация IsPasswordExpired () одинакова для новых и существующих членов.

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;
   }
}

Если у вас есть отдельное требование о том, что вновь создаваемые участники должны обновить свой пароль, я бы добавил отдельное логическое поле с именем passwordShouldBeChanged и установил бы его в значение true при создании. Затем я бы изменил функциональность метода IsPasswordExpired (), чтобы включить проверку для этого поля (и переименовал метод в 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;
   }
}

Сделайте ваши намерения явными в коде.

Во-первых, нулевые значения, являющиеся злом, являются догмой, и, как обычно, с догмой, они работают лучше всего в качестве ориентира, а не в качестве теста «сдать / не пройти».

Во-вторых, вы можете переопределить вашу ситуацию таким образом, чтобы иметь смысл, что значение никогда не может быть нулевым. InititialPasswordChanged - это логическое значение, изначально установленное на false, PasswordSetTime - это дата и время, когда был установлен текущий пароль.

Обратите внимание, что хотя это и требует небольших затрат, теперь вы ВСЕГДА можете рассчитать, сколько времени прошло с момента последней установки пароля.

Оба являются «безопасными / нормальными / правильными», если вызывающий проверяет перед использованием. Проблема в том, что произойдет, если звонящий не проверит. Что лучше, какая-то разновидность нулевой ошибки или использование недопустимого значения?

Нет единого правильного ответа. Это зависит от того, что вы беспокоитесь.

Если сбои действительно плохие, но ответ не является критическим или имеет принятое значение по умолчанию, тогда, возможно, лучше использовать логическое значение в качестве флага. Если использование неправильного ответа является более серьезной проблемой, чем сбой, тогда лучше использовать null.

Для большинства «типичных» случаев быстрый сбой и принуждение вызывающих абонентов к проверке - это самый быстрый путь к здравому коду, и, следовательно, я думаю, что значение по умолчанию должно быть null Я бы не стал слишком верить в евангелистов «Икс - корень всех злых»; они обычно не ожидали всех вариантов использования.