Null Object Pattern, чтобы избежать нулевых проверок?

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

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

Хотя шаблон нулевого объекта имеет свое применение, вам все равно нужно будет сделать проверку здесь, иначе вы попытаетесь sendEmail() отправить адрес электронной почты, который является пустой строкой (или вы поместите проверку в sendEmail(), что может так же легко проверить наличие null).

Здесь шаблон нулевого объекта был бы действительно полезен, если бы класс CustomerVO реализовал метод sendEmail(). тогда вы можете просто связать вызовы вместе, поскольку контракт getCustomer() гарантирует, что ссылка null не будет возвращена:

CustomerDAO.getCustomer(customerID).sendEmail();

В этом случае метод sendEmail() проверит, что его попросили воздействовать на специальный «нулевой объект», и просто ничего не сделает (или что-то еще).

Должен ли ваш метод getCustomer вызывать исключение, если клиент не найден, а не возвращать null?

Ответ, конечно, заключается в том, что это зависит от обстоятельств: должно ли почти никогда не быть случая, когда идентификатор клиента не существует? Другими словами, является ли это исключительным обстоятельством? Если да, то допустимо исключение.

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

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

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

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

Метод CustomerVO custVO = CustomerDAO.getCustomer(customerID); делает две вещи.

Во-первых, он возвращает клиента, если он существует, и, во-вторых, возвращает ноль, если такого клиента нет. Это две разные операции, и их следует кодировать соответствующим образом.

Лучшим подходом будет:

bool customerExists = CustomerDAO.exists(customerID);

if (customerExists)
{
  CustomerVO custVO = CustomerDAO.getCustomer(customerID);
  sendEmail(custVO.getFirstName(), custVO.getEmailID());
}
else
{
   // Do whatever is appropriate if there is no such customer.
}

}

Итак, разделите метод на два, один из которых проверяет, существует ли запрошенный объект, а второй фактически извлекает его. Нет необходимости в каких-либо исключениях, а дизайн и семантика очень ясны (что, на мой взгляд, с шаблоном «не существует-возвращает-нуль» не так). Более того, в этом подходе метод CustomerDAO.getCustomer(customerID) выдает ArgumentException, если запрошенный клиент не существует. В конце концов, вы просили Customer, а его нет.

Кроме того, на мой взгляд, ни один метод не должен возвращать null. Null явно означает: «Я не знаю, какой правильный ответ, мне нечего возвращать». Null - это не смысл, это отсутствие смысла. Спросите себя: «Почему я возвращаю то, что, как я знаю, не должно происходить на самом деле?» Ваш метод GetCustomer должен, очевидно, возвращать Customer. Если вы возвращаете null, вы просто перекладываете ответственность за то, что делать, на цепочку вызовов и нарушаете контракт. Если есть значимое значение по умолчанию, используйте его, но исключение здесь может заставить вас задуматься о правильном дизайне.

Имя является шаблоном проектирования NULL объекта, а не шаблоном проектирования NULL check. Нулевой объект означает отсутствие объекта. Это следует использовать, когда у вас есть объекты, работающие в СОТРУДНИЧЕСТВЕ. В вашем случае вы проверяете наличие объекта, для которого проверка NULL должна быть в порядке.

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

Проверки NULL не следует заменять объектами шаблона проектирования NULL, поскольку это может привести к скрытым дефектам в приложении.

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

http://www.codeproject.com/Articles/1042674/NULL-Object-Design-Pattern