É necessário que métodos setter para ter um argumento?

Question

É necessário que métodos setter para ter um argumento? Normalmente métodos setter aceitar um argumento como o valor de uma determinada propriedade de um objeto. E se eu quiser testar primeiro a validade que depende de outro argumento que é um booleano, se for verdade, validar primeiro, então apenas definir o valor.

Estou recebendo os valores de clientes através do servidor ftp. Às vezes, esses arquivos contêm valores de lixo. Por exemplo, um número de telefone como # 3432838 # 9. Então, antes de definir o valor Eu preciso remover esses caracteres de lixo. Posso fazê-lo nos métodos setter? É uma abordagem válida?

Graças um bando de antecedência!

EDIT:

É este válido:

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

Answer 1

É necessário especificamente no modelo de framework java feijão, mas ele s não é obrigatória em geral.

Você pode ter setter sem discussão quando elas são destinadas a "switch" um valor.

void setCheck()

poderia, por exemplo, ser feitos para definir o "cheque" atributo booleano para true.

Assim, mesmo se ele não é um "setter" no sentido java feijão do termo, você pode imaginar setter utilizado para outros fins.

Além disso, de acordo com a secção 7 de especificações JavaBean, um setter pode ter mais de um argumento , por exemplo, para propriedades indexadas (uma propriedade indexada suporta uma gama de valores. Sempre que a propriedade é lido ou escrito que você acabou de especificar um índice para identificar qual o valor que quiser.)

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

---

No seu caso, uma abordagem válida seria a de adicionar um exceção tempo de execução para a assinatura da nossa função.
Dessa forma, você não colocar qualquer em tempo de compilação verificação exceção desnecessária para todas as outras classes que já estão chamando seu setter.

Ou você poderia considerar sua propriedade como um Restrições propriedade e adicione uma exceção não-execução.

métodos propriedade setter constrangidos são necessários para apoiar o PropertyVetoException. Este documento para os usuários da propriedade restrita que tentaram atualizações podem ser vetado. Assim, um simples constrangidos propriedade pode parecer:

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

que permite VetoableChangeListener a ser adicionado, se necessário.

---

Quanto à sua trecho, é "válido", mas pode não ser o ideal, porque (como disse em esta questão ):

• A validação deve ser capturado separadamente getters ou setters em um método de validação. Dessa forma, se as necessidades de validação para ser reutilizado em vários componentes, está disponível.
• É melhor falhar rapidamente (daí a minha proposta para adicionar exceção à setter).

Answer 2

Por especificação Java Bean setter tem um argumento. Se você adicionar um outro, por qualquer motivo, não é considerado mais setter.

Setter é perfeitamente válido "se limpar" o seu argumento, ou exceção lance se é inválido.

Answer 3

Por que não. Verificar e validar a entrada é um bom variante para incluir na incubadora. A questão aqui é que, se você deseja permitir definindo o membro sem validação.

Possivelmente você precisa a forma-padrão do setter por algum quadro que você usa (uso como feijão). Mas se você não está restrito, desta forma, você pode tentar isso.

Você também pode usar afirma no setter, se você acha outro código deve fazer os valores de validação, mas erradas nunca deve definir.

Answer 4

No livro "Effective Java 2nd Edition" por Joshua Bloch (ISBN-13: 978-0-321-35668-0). Saids que é melhor usar o padrão do construtor do que a convenção de feijão para criações objetos

Por exemplo (padrão de feijão):

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

Uso com padrão do construtor:

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

A implementação do padrão do construtor:

// 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;
    }
}

Quando os dois primeiros argumentos AR necessário.
Para a validação você pode usar validação precoce (em cada método <field>) ou validação preguiçoso (no método build ()). E o formato é tipo de inicialização de valores-chave python.