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

Question

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

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

Заранее большое спасибо!

EDIT:

Действительно ли это:

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

Answer 1

Это необходимо конкретно в каркасной модели Java-бина, но в целом это не обязательно.

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

void setCheck()

Например,

может означать, что для логического атрибута "check" установлено значение true.

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

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

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

---

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

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

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

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

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

---

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

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

Answer 2

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

Установщик вполне допустим, чтобы «очистить» свой аргумент или выдать исключение, если он недействителен.

Answer 3

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

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

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

Answer 4

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

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

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.