Возвращает нулевой плохой дизайн? [закрыто]

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

псевдокод:

variable x = object.method()
if (x is null) do something

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

Например, если бы я определил в Java метод, возвращающий коллекцию, я бы обычно предпочел возвращать пустую коллекцию (т.е. Collections.emptyList()), а не ноль, поскольку это означает, что мой клиентский код чище; например

Collection<? extends Item> c = getItems(); // Will never return null.

for (Item item : c) { // Will not enter the loop if c is empty.
  // Process item.
}

... что чище, чем:

Collection<? extends Item> c = getItems(); // Could potentially return null.

// Two possible code paths now so harder to test.
if (c != null) {
  for (Item item : c) {
    // Process item.
  }
}

Вот причина.

В « Чистом коде» Роберта Мартина он пишет, что возвращение нуля - плохой дизайн, когда вместо этого можно вернуть, скажем, пустой массив. Поскольку ожидаемый результат - это массив, почему бы и нет? Это позволит вам перебирать результат без каких-либо дополнительных условий. Если это целое число, может быть достаточно 0, если это хеш, пустой хеш. и т.п.

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

Хорошее использование возврата null:

• Если null является допустимым функциональным результатом, например: FindFirstObjectThatNeedsProcessing () может вернуть null, если не найден, и вызывающий должен проверить соответственно.

Плохое использование: попытка заменить или скрыть исключительные ситуации, такие как:

• catch (...) и вернуть null
• Ошибка инициализации зависимости API
• Недостаточно места на диске
• Неверные входные параметры (ошибка программирования, входные данные должны быть очищены вызывающим абонентом)
• и т.д

В этих случаях более адекватным является создание исключения, поскольку:

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

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

• Неверное имя пользователя / пароль (или любые введенные пользователем данные)
• Разрыв петель или нелокальных переходов

Да, возвращение NULL - ужасный дизайн в объектно-ориентированном мире. Вкратце, использование NULL приводит к:

• специальная обработка ошибок (вместо исключений)
• неоднозначная семантика
• медленно, а не быстро
• компьютерное мышление вместо объектного мышления
• изменяемые и неполные объекты

Подробное объяснение можно найти в этом сообщении в блоге: http://www.yegor256.com/2014/05/13/why-null-is-bad.html . Подробнее в моей книге « Элегантные объекты» , раздел 4.1.

Кто сказал, что это плохой дизайн?

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

Исходя из того, что вы сказали до сих пор, я думаю, что информации недостаточно.

Возврат null из метода CreateWidget () кажется плохим.

Возврат null из метода FindFooInBar () кажется прекрасным.

Его изобретатель говорит, что это ошибка на миллиард долларов!

Это зависит от языка, который вы используете. Если вы работаете в таком языке, как C #, где идиоматический способ указать отсутствие значения - это вернуть null, тогда возврат null - хороший вариант, если у вас нет значения. В качестве альтернативы, в таких языках, как Haskell, которые идиоматически используют монаду Maybe для этого случая, возвращение null было бы плохим дизайном (если бы это было вообще возможно).

Если вы прочтете все ответы, станет ясно, что ответ на этот вопрос зависит от типа метода.

Во-первых, когда происходит что-то исключительное (проблема ввода-вывода и т. Д.), Логически возникают исключения. Когда что-то особенное - это, вероятно, тема для другой темы ..

Всякий раз, когда ожидается, что метод не даст результатов, есть две категории:

• Если возможно вернуть нейтральное значение, сделайте это .
  Пустые перечисления, строки и т. Д. - хорошие примеры
• Если такое нейтральное значение не существует, следует вернуть null .
  Как уже упоминалось, предполагается, что метод, возможно, не даст результата, поэтому он не является исключительным и, следовательно, не должен вызывать исключение. Нейтральное значение невозможно (например: 0 не является особенно нейтральным результатом, в зависимости от программы)

Пока у нас не будет официального способа обозначить, что функция может или не может возвращать значение null, я стараюсь иметь соглашение об именах, чтобы обозначить это.
Так же, как у вас есть соглашение Try Something () для методов, которые, как ожидается, не сработают, я часто называю свои методы Safe Something () когда метод возвращает нейтральный результат вместо null.

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

У меня есть конвенция в этой области, которая мне хорошо послужила

Для запросов по одному элементу:

• Create...возвращает новый экземпляр или бросает
• Get...возвращает ожидаемый существующий экземпляр или бросает
• GetOrCreate...возвращает существующий экземпляр или новый экземпляр, если его нет, или бросает
• Find...возвращает существующий экземпляр, если он существует, илиnull

Для запросов по сбору:

• Get... всегда возвращает коллекцию, которая пуста, если не найдено подходящих [1] элементов

[1] с учетом некоторых критериев, явных или неявных, указанных в имени функции или в качестве параметров.

Исключения составляют исключения обстоятельства.

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

Если это имеет какое-то значение, можно вернуть null:

public String getEmployeeName(int id){ ..}

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

Люди могут подумать, что это плохо, потому что им можно злоупотреблять как «специальное» возвращаемое значение, указывающее на состояние ошибки, что не так хорошо, немного похоже на возвращение кодов ошибок из функции, но сбивает с толку, потому что пользователь должен проверить возвращаемый результат для null вместо того, чтобы перехватывать соответствующие исключения, например

public Integer getId(...){
   try{ ... ; return id; }
   catch(Exception e){ return null;}
}

Это не обязательно плохой дизайн - это зависит от многих дизайнерских решений.

Если результатом метода является то, что не дало бы хорошего результата при нормальном использовании, можно вернуть null:

object x = GetObjectFromCache();   // return null if it's not in the cache

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

try {
   Controller c = GetController();    // the controller object is central to 
                                      //   the application. If we don't get one, 
                                      //   we're fubar

   // it's likely that it's OK to not have the try/catch since you won't 
   // be able to really handle the problem here
}
catch /* ... */ {
}

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

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

Более того, игнорирование ошибок может привести к уязвимостям безопасности. Возможно, пустота возникла из-за того, что буфер был перезаписан или что-то подобное. Теперь у вас нет сбоев, а это значит, что у эксплуататора есть шанс выполнить свой код.

Какие альтернативы вы видите возвращению null?

Я вижу два случая:

• findAnItem (идентификатор). Что делать, если предмет не найден

В этом случае мы могли бы: вернуть Null или выбросить (проверенное) исключение (или, возможно, создать элемент и вернуть его)

• listItemsMatching (критерии) что это должно возвращать, если ничего не найдено?

В этом случае мы могли бы вернуть Null, вернуть пустой список или выдать исключение.

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

x = find();
x.getField();  // bang null pointer exception

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

Я считаю, что поиск, возвращающий пустые списки, может быть довольно удобным - просто заполните дисплей всем содержимым списка, о, он пуст, код «просто работает».

Иногда возвращение NULL является правильным решением, но особенно, когда вы имеете дело с последовательностями разного типа (массивы, списки, строки и т. Д.), Вероятно, лучше вернуть последовательность нулевой длины, поскольку она приводит к более короткому и, надеюсь, более понятному коду, не требуя при этом гораздо большего количества написания со стороны разработчика API.

Заставьте их вызвать другой метод постфактум, чтобы выяснить, был ли предыдущий вызов нулевым. ;-) Эй, для JDBC хватило

Основная идея этой темы - защитное программирование. То есть код против неожиданного. Есть множество разных ответов:

Адамски предлагает посмотреть на образец нулевого объекта, и этот ответ был одобрен за это предложение.

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

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

Но у нас есть 2 сценария развития.

Классы «авторские» разработчик: Автор

Классы, "потребляемые" другим (возможно) разработчиком: Разработчик

Независимо от того, возвращает ли класс NULL для методов с возвращаемым значением или нет, разработчику необходимо проверить, действителен ли объект.

Если разработчик не может этого сделать, то этот класс / метод не является детерминированным. То есть, если «вызов метода» для получения объекта не выполняет то, что он «рекламирует» (например, getEmployee), это нарушает контракт.

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

Итак, учитывая, что либо NULL, либо NULL OBJECT (например, if (employee as NullEmployee.ISVALID)) необходимо проверить, и это может потребоваться с коллекцией сотрудников, то подход с нулевым объектом является лучшим подходом.

Но мне также нравится предложение Майкла Валенти назвать метод, который ДОЛЖЕН возвращать значение null, например getEmployeeOrNull.

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

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

Итак, как разработчик, я должен защищать метод от NULL. Если автор дал мне контракт, который всегда возвращает объект (всегда возвращает NULL OBJECT), и этот объект имеет метод / свойство, с помощью которого можно проверить действительность объекта, то я бы использовал этот метод / свойство для продолжения использования объекта. , иначе объект недействителен, и я не могу его использовать.

Суть в том, что Автор класса / методов должен предоставить механизмы, которые Разработчик может использовать в своем защитном программировании. То есть более четкое намерение метода.

Разработчик всегда должен использовать защитное программирование для проверки достоверности объектов, возвращаемых другим классом / методом.

С уважением

GregJF

Другие варианты для этого: возврат некоторого значения, которое указывает на успех или нет (или тип ошибки), но если вам просто нужно логическое значение, которое будет указывать на успех / неудачу, возврат null для неудачи, а объект для успеха не быть менее правильным, затем вернуть истину / ложь и получить объект через параметр. Поэтому я лично не вижу ничего плохого в том, чтобы возвращать null как указание на то, что что-то пошло не так, и проверять его позже (чтобы узнать, удалось ли вам это или нет). Кроме того, слепо полагая, что ваш метод не вернет NULL, а затем основывает свой код на нем, может привести к другим, иногда трудным для поиска ошибкам (хотя в большинстве случаев это просто приведет к сбою вашей системы :), как вы будете ссылаться на 0x00000000 рано или поздно).
Другой подход - использовать исключение для указания сбоев, но здесь на самом деле гораздо больше голосов, которые говорят, что это ПЛОХОЙ метод (поскольку использование исключений может быть удобным, но имеет много недостатков).

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

Нулевая функция или метод часто используется как поведение по умолчанию для обнаруживаемой функции или переопределяемого метода в объектной структуре.

Null_function @wikipedia

Ну, конечно, это зависит от цели метода ... Иногда лучше было бы выбросить исключение. Все зависит от случая к случаю.

Если код выглядит примерно так:

command = get_something_to_do()

if command:  # if not Null
    command.execute()

Если у вас есть фиктивный объект, метод execute () которого ничего не делает, и вы возвращаете его вместо Null в соответствующих случаях, вам не нужно проверять регистр Null, и вместо этого вы можете просто сделать:

get_something_to_do().execute()

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

Для моего случая использования мне нужно было вернуть Map from метод, а затем искать определенный ключ. Но если я верну пустую карту, это приведет к NullPointerException, и тогда это не будет сильно отличаться от возврата null вместо пустой карты. Но начиная с Java8 мы могли использовать Optional . Вышеупомянутое и является причиной введения дополнительной концепции.

G'day,

Возвращение NULL, когда вы не можете создать новый объект, является стандартной практикой для многих API.

Почему, черт возьми, это плохой дизайн, понятия не имею.

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

НТН

«Avahappy,