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

Question

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

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

Заранее спасибо огромное!

РЕДАКТИРОВАТЬ:

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

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

Answer 1

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

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

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 есть один аргумент.Если вы по какой-либо причине добавите еще один, он больше не будет считаться установщиком.

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

Answer 3

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

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

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

Answer 4

В книге Джошуа Блоха «Эффективная Java, 2-е издание» (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.