Необходимо ли проверить на неправильные значения параметров в конструкторе?

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

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

Так, если они передадут значение 107%, то я установлю его на 100%. Я просто проясняю в документации, что это - то, что происходит.

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

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

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

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

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

• Проверка аргументов в конструкторе похожа на проверку аргументов в пользу традиционного метода..., таким образом, я не дифференцировался бы здесь...
• Проверка аргументов метода, конечно, помогает гарантировать, что параметры передали, корректны, но также и представляет много большего количества кода, который необходимо написать, который не всегда окупается, по-моему... Особенно, когда Вы действительно пишете сокращенные методы, которые делегируют вполне часто к другим методам, я предполагаю, что Вы закончили бы с 50% Вашего кода, просто делающего проверки параметра...
• Кроме того, полагайте, что очень часто, когда Вы пишете модульный тест на свой класс, Вы не хотите должными быть передавать в допустимых параметрах для всех методов... Довольно часто действительно имеет смысл только передавать те параметры, важные для текущего тестового сценария, так наличие проверок замедлило бы Вас в записи модульных тестов...

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

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

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

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

Пример. Извините мой неизогнутый синтаксис фигурной скобки:

// precondition b<>0
function divide(a,b:double):double;
begin
  assert(b<>0); // in case of a programming error. 
  result := a / b;
end;

// calling code should be:
if foo<>0 then
  bar := divide(1,0)
else
  // do whatever you need to do when foo equals 0

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

// no preconditions.. still need to check the result
function divide(a,b:double; out hasResult:boolean):double;
begin
  hasResult := b<>0; 
  if not hasResult then
    Exit;
  result := a / b;
end;

// calling code:
bar := divide(1,0,result);
if not result then
  // do whatever you need to do when the division failed

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

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