Умнее сеттер? Хорошая или плохая идея?

Question

В растворе GWT. (так что это код Java, который затем компилируется в JavaScript). Есть конечно несколько классов.

Является ли хорошей идеей сделать проверку установщика для Null в поле String?

как то так

public void setSomeField(String someField){
  if (null != someField)
    this.someField = someField;
  else
    this.someField = String.Empty;
}

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

Мысли? Спасибо

Answer 1

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

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

Вот почему я начал реализовывать свойства SafeXX. Допустим, у меня было «myObj.Name», которое могло бы иметь нулевое значение, также было бы свойство «myObj.SafeName», которое перехватывало ноль в геттере и возвращало вместо него string.empty. Небольшое соглашение об именах говорит о том, что оно не является обычным получателем.

Answer 2

Вот что нужно учитывать. Вы ожидаете, что этот модульный тест пройдет или не пройдёт?:

yourClass.setSomeField(null);
assertNull(yourClass.getSomeField());

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

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

Answer 3

Если null действительно нужно изменить на "" по уважительной причине (например, это может означать «мне все равно», а по умолчанию может быть ""), перейдите к нему (но задокументируйте его) ).

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

Answer 4

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

Я лично (если вообще) не сделал бы это в сеттере. Внутри вашего класса null должен иметь собственное значение. Если вы для удобства получатель

return (this.someField != null) ? this.someField: String.Empty;

будет делать. Вы бы сохраняли значение null внутри, чтобы иметь дело с внешним, но есть более удобный метод.

Вообще и лично я бы не стал этого делать. Поначалу все выглядит хорошо, а в будущем многое становится сложнее.

Answer 5

Если вы не хотите, чтобы для поля было установлено значение NULL, не устанавливайте для него значение NULL.

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

Answer 6

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

Предположим, вы запрашиваете 'someField' с этим:

select * from ... where someField is null

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