Если функции должны выполнить нулевые проверки перед выполнением намеченного поведения, это плохой дизайн?

Так что я не знаю, хороший это или плохой дизайн кода, поэтому я подумал, что лучше спросить.

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

Для очень простого примера:

// fields and properties
private Entity _someEntity;
public Entity SomeEntity => _someEntity;

public void AssignEntity(Entity entity){
    _someEntity = entity;
}
public void SetName(string name)
{
    if (_someEntity == null) return; //check to avoid null ref
    _someEntity.Name = name;
    label.SetText(_someEntity.Name);
}

Так что, как вы можете видеть, я проверяю нулевое значение каждый раз. Но должен ли метод не иметь эту проверку?

Например, внешний код должен очищать данные перед использованием, чтобы методы не проверялись, как показано ниже:

 if(entity != null) // this makes the null checks redundant in the methods
 {
     Manager.AssignEntity(entity);
     Manager.SetName("Test");
 }

Таким образом, если методы «проверяют данные», а затем выполняют их обработку данных, или это должно быть гарантировано перед вызовом метода, и если вам не удалось проверить перед вызовом метода, он должен выдать ошибку (или перехватить ошибка)?

Проблема с вашим базовым примером не в нулевой проверке, а в тихом сбое .

Ошибки нулевого указателя / ссылки чаще всего являются ошибками программиста. Ошибки программиста часто лучше всего устраняются путем немедленного и громкого сбоя. У вас есть три основных способа решения проблемы в этой ситуации:

1. Не беспокойтесь о проверке, а просто дайте среде выполнения сгенерировать исключение nullpointer.
2. Проверьте и сгенерируйте исключение с сообщением лучше, чем базовое сообщение NPE.

Третье решение - больше работы, но гораздо надежнее:

3. Создайте свой класс таким образом, чтобы он _someEntityникогда не был в недопустимом состоянии. Один из способов сделать это - избавиться от него AssignEntityи потребовать его в качестве параметра для создания экземпляра. Другие методы внедрения зависимости также могут быть полезны.

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

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

Поскольку _someEntityего можно изменить на любом этапе, имеет смысл проверять его каждый раз, когда SetNameвызывается. В конце концов, это могло измениться с момента последнего вызова этого метода. Но имейте в виду, что код SetNameне является потокобезопасным, поэтому вы можете выполнить эту проверку в одном потоке, _someEntityустановить в nullдругой, и тогда код все NullReferenceExceptionравно будет заблокирован .

Поэтому один из подходов к этой проблеме - стать еще более оборонительным и выполнить одно из следующих действий:

1. сделать локальную копию _someEntityи ссылку на эту копию с помощью метода,
2. использовать блокировку вокруг, _someEntityчтобы убедиться, что она не изменяется при выполнении метода,
3. используйте a try/catchи выполняйте те же действия с любыми NullReferenceExceptionобъектами, которые встречаются в методе, что вы выполняете при первоначальной проверке нуля (в данном случае nopдействие).

Но что вам действительно нужно сделать, так это остановиться и задать себе вопрос: нужно ли вам на самом деле разрешить _someEntityперезапись? Почему бы не установить его один раз, через конструктор. Таким образом, вам нужно всего лишь сделать эту нулевую проверку один раз:

private readonly Entity _someEntity;

public Constructor(Entity someEntity)
{
    if (someEntity == null) throw new ArgumentNullException(nameof(someEntity));
    _someEntity = someEntity;
}

public void SetName(string name)
{
    _someEntity.Name = name;
    label.SetText(_someEntity.Name);
}

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

В качестве бонуса я чувствую, что ваш код странный и может быть улучшен. Все:

private Entity _someEntity;
public Entity SomeEntity => _someEntity;

public void AssignEntity(Entity entity){
    _someEntity = entity;
}

можно заменить на:

public Entity SomeEntity { get; set; }

Имеет ту же функциональность, за исключением возможности устанавливать поле через установщик свойств, а не метод с другим именем.

Но должен ли метод не иметь эту проверку?

Это твой выбор.

Создавая publicметод, вы предлагаете общественности возможность его вызвать. Это всегда сопровождается неявным договором о том, как вызывать этот метод и что ожидать при этом. Этот контракт может (или не может) включать « да, хм, если вы передадите nullв качестве значения параметра, он взорвется прямо на вашем лице ». Другие части этого контракта могут быть « о, кстати: каждый раз, когда два метода выполняют этот метод одновременно, котенок умирает ».

Какой тип контракта вы хотите разработать, зависит от вас. Важные вещи должны

• создать API, который является полезным и последовательным и

• хорошо документировать это, особенно для тех крайних случаев.

Каковы вероятные случаи, когда ваш метод вызывается?

Другие ответы хороши; Я хотел бы расширить их, сделав несколько комментариев о модификаторах доступности. Во-первых, что делать, если nullникогда не действует:

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

• внутренние и частные методы являются те , где вы действительно контролировать абонент. Они должны утверждать, когда передано нуль; потом они, вероятно, вылетят позже, но, по крайней мере, вы сначала получили утверждение и возможность взломать отладчик. Опять же, вы хотите научить своих абонентов правильно звонить вам, делая это больно, когда они этого не делают.

Теперь, что вы делаете, если это может быть допустимым для передачи нулевого значения? Я бы избежал этой ситуации с шаблоном нулевого объекта . То есть: создайте специальный экземпляр типа и потребуйте, чтобы он использовался каждый раз, когда требуется недопустимый объект . Теперь вы снова в приятном мире бросания / утверждения при каждом использовании нуля.

Например, вы не хотите быть в такой ситуации:

class Person { ... }
...
class ExpenseReport { 
  public void SubmitReport(Person approver) { 
    if (approver == null) ... do something ...

и на сайте вызова:

// I guess this works but I don't know what it means
expenses.SubmitReport(null); 

Потому что (1) вы обучаете своих вызывающих, что null является хорошим значением, и (2) неясно, какова семантика этого значения. Скорее сделайте это:

class ExpenseReport { 
  public static readonly Person ApproverNotRequired = new Person();
  public static readonly Person ApproverUnknown = new Person();
  ...
  public void SubmitReport(Person approver) { 
    if (approver == null) throw ...
    if (approver == ApproverNotRequired) ... do something ...
    if (approver == ApproverUnknown) ... do something ...

И теперь сайт вызова выглядит так:

expenses.SubmitReport(ExpenseReport.ApproverNotRequired);

и теперь читатель кода знает, что это значит.

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

public static class Foo {
    public static void Frob(Bar a, Bar b) {
        if (a == null) throw new ArgumentNullException(nameof(a));
        if (b == null) throw new ArgumentNullException(nameof(b));

        a.Something = b.Something;
    }
}

Это дает вам преимущество в обслуживании. Если в вашем коде когда-либо возникает дефект, когда что-то передает нулевой объект методу, вы получите полезную информацию от метода относительно того, какой параметр был нулевым. Без проверок вы получите NullReferenceException в строке:

a.Something = b.Something;

И (учитывая, что свойство Something является типом значения), a или b могут иметь значение null, и вы не сможете узнать, какой из трассировки стека. С помощью проверок вы будете точно знать, какой объект был нулевым, что может быть чрезвычайно полезно при попытке выявить дефект.

Я хотел бы отметить, что шаблон в вашем исходном коде:

if (x == null) return;

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

Нет, совсем нет, но это зависит.

Вы только делаете нулевую проверку ссылки, если хотите реагировать на это.

Если вы выполняете проверку нулевой ссылки и генерируете проверенное исключение , вы заставляете пользователя метода реагировать на него и позволяете ему восстановиться. Программа по-прежнему работает, как и ожидалось.

Если вы не выполните проверку нулевой ссылки (или сгенерируете непроверенное исключение), он может выдать непроверенную проверкуNullReferenceException , которая обычно не обрабатывается пользователем метода и даже может завершить работу приложения. Это означает, что функция, очевидно, полностью неправильно понята и, следовательно, приложение неисправно.

Что-то вроде расширения ответа @ null, но, по моему опыту, делать нулевые проверки, несмотря ни на что.

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

Теперь, как вы на самом деле имеете дело со nullзначением, это во многом зависит от вашего варианта использования.

Если nullэто допустимое значение, например, любой из параметров со второго по пятый для подпрограммы MSVC _splitpath (), то правильное поведение в нем.

Если nullэтого не произойдет при вызове рассматриваемой подпрограммы, т. Е. В случае OP, контракт API требует, AssignEntity()чтобы он был вызван с допустимым значением, а Entityзатем выдает исключение или иным образом завершается неудачей, гарантируя, что вы создадите много шума в процессе.

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