Est-il nécessaire que les méthodes setter aient un argument?

Question

Est-il nécessaire que les méthodes setter aient un argument? Habituellement, les méthodes de définition acceptent un argument comme valeur d'une certaine propriété d'un objet. Et si je veux d’abord tester la validité qui dépend d’un autre argument booléen, si true, validez d’abord, sinon définissez simplement la valeur.

Je reçois les valeurs des clients via le serveur FTP. Parfois, ces fichiers contiennent des valeurs parasites. Par exemple, un numéro de téléphone comme # 3432838 # 9. Donc, avant de définir la valeur, j'ai besoin de supprimer ces caractères illisibles. Puis-je le faire dans les méthodes setter? Est-ce une approche valable?

Merci beaucoup d'avance!

EDIT:

Est-ce valide:

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

Answer 1

Cela est nécessaire en particulier dans le modèle de cadre Java Bean, mais ce n’est pas obligatoire en général.

Vous pouvez avoir un paramètre sans argument quand ils sont destinés à & "; swith &"; une valeur.

void setCheck()

pourrait par exemple être destiné à définir le & "vérifier &"; attribut booléen à true.

Donc même si ce n'est pas un " configurateur & "; au sens java bean du terme, vous pouvez imaginer un setter utilisé à d’autres fins.

De plus, conformément à la section 7 des spécifications JavaBean, un séparateur peut avoir plusieurs arguments , par exemple pour les propriétés indexées (une propriété indexée prend en charge une plage de valeurs. Chaque fois que la propriété est lue ou écrit vous venez de spécifier un index pour identifier quelle valeur vous voulez.)

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

Dans votre cas, une approche valide consisterait à ajouter un exception d'exécution à la signature de notre fonction.
De cette manière, vous ne mettez pas d'exception inutile lors de la compilation lors de la compilation pour toutes les autres classes qui appellent déjà votre setter.

Vous pouvez également considérer votre propriété comme une propriété contrainte et ajouter une exception autre que d'exécution.

Des méthodes de définition de propriétés contraintes sont nécessaires pour prendre en charge la PropertyVetoException. Cette documentation aux utilisateurs de la propriété contrainte qui a tenté des mises à jour peut être veto. Donc, une simple propriété contrainte peut ressembler à:

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

qui permet d'ajouter VetoableChangeListener si nécessaire.

En ce qui concerne votre extrait, il est & "valide &"; mais peut ne pas être optimale car (comme indiqué dans cette question ):

• La validation doit être saisie séparément des getters ou des setters dans une méthode de validation. Ainsi, si la validation doit être réutilisée sur plusieurs composants, elle est disponible.
• Il est préférable de échouer rapidement (d'où ma proposition d'ajouter une exception au configurateur).

Answer 2

Par spécificateur Java Bean avoir un argument. Si vous en ajoutez un autre, pour quelque raison que ce soit, il n'est plus considéré comme un fixateur.

Le

Setter est parfaitement valide pour & "Nettoyer &"; son argument ou lève une exception si est invalide.

Answer 3

Pourquoi pas. La vérification et la validation de l'entrée sont une bonne variante à inclure dans le configurateur. La question est la suivante: si vous souhaitez autoriser la définition du membre sans validation.

Vous avez peut-être besoin de la forme standard du setter pour le framework que vous utilisez (utilisation comme bean). Mais si vous n'êtes pas limité de cette manière, vous pouvez essayer ceci.

Vous pouvez également utiliser des assertions dans le sélecteur si vous pensez qu'un autre code devrait effectuer la validation mais que des valeurs incorrectes ne doivent jamais être définies.

Answer 4

Dans le livre " Effective Java 2nd Edition " de Joshua Bloch (ISBN-13: 978-0-321-35668-0) déclare qu'il est préférable d'utiliser le modèle de générateur que la convention de bean pour les créations d'objets.

Par exemple (motif de haricot):

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

Utilisation avec le modèle de générateur:

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

L'implémentation du modèle de générateur:

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

Lorsque les deux premiers arguments sont requis.
Pour la validation, vous pouvez utiliser la validation précoce (dans chaque méthode <field>) ou la validation différée (dans la méthode build ()). Et le format est une sorte d’initialisation clé-valeur en python.