Должен ли я возвращать нуль из или применять шаблон «нулевой объект» к функции, возвращающей дату?

Question

Допустим, у вас есть функция, которая возвращает дату:

Date myFunc(paramA, paramB){
   //conditionally return a date?
}

Уместно ли возвращать null из этой функции? Это кажется уродливым, потому что заставляет клиентов проверять null.

Шаблон "нулевого объекта" является шаблоном реализации, который решает эту проблему.
Я не большой поклонник шаблона нулевого объекта, но да, имеет смысл всегда возвращать список, даже если он пуст, а не возвращать null.
Однако, скажем в Java, нулевая дата будет очищена и имеет год 1970.

Каков наилучший шаблон реализации здесь?

Answer 1

Шаблон нулевого объекта не для того, что вы пытаетесь сделать. Этот шаблон предназначен для создания объекта без функциональности в его реализации, который вы можете передать данной функции, которая требует, чтобы объект не был нулевым. Примером является NullProgressMonitor в Eclipse, который является пустой реализацией IProgressMonitor .

Если вы вернете «нулевую» дату, например, 1970, ваши клиенты все равно должны будут проверить, является ли она «нулевой», увидев, что это 1970. А если нет, произойдет неправильное поведение. Однако, если вы вернете ноль, их код быстро потерпит неудачу, и они будут знать, что они должны проверить на ноль. Кроме того, 1970 может быть действительной датой.

Вы должны документально подтвердить, что ваш метод может возвращать ноль, и все.

Answer 2

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

Answer 3

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

Документ, который может вернуть нулевое значение, однако ...

Answer 4

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

Шаблон объекта Null не подходит для этого случая, как уже было сказано. На самом деле, исходя из собственного опыта, это не подходит для многих случаев. Конечно, у меня есть некоторая предвзятость из-за некоторого опыта неправильного использования; -)

Answer 5

Я не фанат шаблона нулевого объекта.

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

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

Answer 6

Вы можете попробовать использовать выходной параметр

boolean MyFunction( a,b,Date c)
{
  if (good) 
     c.SetDate(....);
  return good;

}

Тогда вы можете назвать это

Date theDate = new Date();
if(MyFunction(a, b ,theDate ) 
{
   do stuff with C
}

Это все еще требует, чтобы вы что-то проверили, но в этом сценарии нет способа избежать проверки.

Хотя SetDate устарела, а реализация Календаря просто ужасна.

Самое глупое изменение API, которое когда-либо делал Sun.

Answer 7

Используйте исключения, если это не тот сценарий, который обычно должен происходить.

В противном случае (если это, например, дата окончания события), просто верните ноль.

Пожалуйста, избегайте магических значений в любом случае;)

Answer 8

Если это не производительность, мне нравится иметь явный метод запроса, а затем использовать исключения:

if(employee.hasCustomPayday()) {
    //throws a runtime exception if no payday
    Date d = emp.customPayday();
}