Нужно ли для методов setter иметь один аргумент?

Question

Нужно ли для методов setter иметь один аргумент? Обычно методы setter принимают один аргумент как значение некоторого свойства объекта. Что делать, если я хочу сначала проверить правильность, которая зависит от другого аргумента, который является логическим, если true, сначала проверьте, иначе просто установите значение.

Я получаю значения от клиентов через ftp-сервер. Иногда эти файлы содержат значения мусора. Например, номер телефона, например # 3432838 # 9. Поэтому, прежде чем я установил значение, мне нужно удалить эти символы мусора. Могу ли я сделать это в методах setter? Это действительный подход?

Спасибо за кучу заранее!

EDIT:

Является ли это действительно:

public void setSomething(String strValue){ 
    if(checkValidity(strValue)){ 
     // set the value 
    } else { 
     // set the value to an empty string 
    } 
    } 

Answer 1

Это необходимо, в частности, в модели фрейма java bean, но это не является обязательным в целом.

У вас может быть сеттер без аргументов, когда они предназначены для «swith» значения.

void setCheck() 

может быть, например, предназначено для установки атрибута «check» boolean на true.

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

Plus, в соответствии с разделом 7 спецификаций бина, сеттер может иметь более чем один аргумент, например, для индексированных свойств (Индексированное свойство поддерживает диапазон значений. Всякий раз, когда свойство чтения или записи вам просто указать индекс, чтобы определить, какое значение вы хотите.)

void setter(int index, PropertyType value); // indexed setter 
void setter(PropertyType values[]); // array setter 

---

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

Или вы можете считать свою недвижимость Ограниченное свойство и добавить исключение без выполнения.

Для обеспечения исключения PropertyVetoException требуются методы настройки ограничений. Эти документы для пользователей ограниченного свойства, которые пытались обновить, могут быть vetoed. Так просто ограничен свойство может выглядеть следующим образом:

PropertyType getFoo(); 
void setFoo(PropertyType value) throws PropertyVetoException; 

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

---

Что касается вашего фрагмента кода, это «действительно», но не может быть оптимальными, поскольку (как сказано в this question):

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

Answer 2

По Java Bean спецификации инкубаторе есть один аргумент. Если вы добавите еще один, по какой-то причине, он больше не считается установщиком.

Setter отлично подходит для «очистки» своего аргумента или исключения исключения, если это недействительно.

Answer 3

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

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

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

Answer 4

В книге «Эффективное Java 2nd Edition» Джошуа Блоха (ISBN-13: 978-0-321-35668-0) говорится, что лучше использовать шаблон строителя, чем соглашение о создании объектов для объектов.

Например (шаблон фасоли):

NutritionFacts cocaCola = new NutritionFacts(); 
cocaCola.setServingSize(240); 
cocaCola.setServings(8); 
cocaCola.setCalories(100); 
cocaCola.setSodium(35); 
cocaCola.setCarbohydrate(27); 

Использование с строитель схеме:

NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8). 
    calories(100). 
    sodium(35). 
    carbohydrate(27). 
    build(); 

Реализация строитель шаблона:

// Builder Pattern 
public class NutritionFacts { 
    private final int servingSize; 
    private final int servings; 
    private final int calories; 
    private final int fat; 
    private final int sodium; 
    private final int carbohydrate; 
    public static class Builder { 
     // Required parameters 
     private final int servingSize; 
     private final int servings; 
     // Optional parameters - initialized to default values 
     private int calories = 0; 
     private int fat = 0; 
     private int carbohydrate = 0; 
     private int sodium = 0; 
     public Builder(int servingSize, int servings) { 
      this.servingSize = servingSize; 
      this.servings = servings; 
     } 
     public Builder calories(int val) 
     { calories = val; return this; } 
     public Builder fat(int val) 
     { fat = val; return this; } 
     public Builder carbohydrate(int val) 
     { carbohydrate = val; return this; } 
     public Builder sodium(int val) 
     { sodium = val; return this; } 
     public NutritionFacts build() { 
      return new NutritionFacts(this); 
     } 
    } 
    private NutritionFacts(Builder builder) { 
     servingSize = builder.servingSize; 
     servings = builder.servings; 
     calories = builder.calories; 
     fat = builder.fat; 
     sodium = builder.sodium; 
     carbohydrate = builder.carbohydrate; 
    } 
} 

Когда первые два аргумента аг обязательный.
Для проверки вы можете использовать раннюю проверку (в каждом методе <field>) или ленивую проверку (в методе build()). И формат является своего рода инициализацией ключа-ключа python.