Modification de l'argument du setter - est-ce un hack ou pas?

Question

Est-il normal de modifier les arguments du sélecteur? Imaginons que nous ayons la méthode setString. Et nous souhaitons vraiment conserver une forme découpée de la chaîne. Donc, une chaîne avec des espaces de fin n'est pas valide, mais nous ne voulons pas lancer une exception.

Quelle est la meilleure solution? Pour ajuster la valeur dans le sélecteur, par exemple

public void setString(String string) {
    this.string = string.trim();
}

Ou coupez l'appelant (plus d'une fois), par exemple

object.setString(string.trim());

Ou peut-être quelque chose d'autre?

Answer 1

Oui. Après tout, les setters sont conçus pour ce genre de choses! Pour contrôler et assainir les valeurs écrites dans les champs;)

Answer 2

Totalement. Voici un exemple: supposons que vous ayez un programme d'ingénierie avec différents types d'unités de mesure. Vous conservez les valeurs internes dans un système de mesure, mais vous convertissez tous les autres dans le setter, puis vous reconvertissez dans le getter, par exemple:

public double UserTemperature
{
  get
  {
    return Units.Instance.ConvertFromSystem(UnitType.Temperature, temperature);
  }
  set  
  {
    double v = Units.Instance.ConvertToSystem(UnitType.Temperature, value);
    if (temperature != v)
    {
      temperature = v;
      Changed("SystemTemperature");
      Changed("UserTemperature");
    }
  }
}

Answer 3

Oui, bien sûr. Veillez simplement à vérifier la valeur NULL avant d’appliquer une méthode (telle que trim ()).

Answer 4

Il y a deux écoles: l’une dit qu’elle peut vérifier les paramètres dans le setter (style scolaire) et la seconde indique que les haricots ne doivent contenir aucune logique ni uniquement des données (style entreprise).

Je crois plus au second. À quelle fréquence regardez-vous la mise en œuvre de vos haricots? getUser devrait-il lever une exception ou renvoyer null?

Lorsque vous mettez de la logique dans votre setter et vos accesseurs, vous avez du mal à comprendre ce qui se passe car beaucoup de gens ne verront jamais sa mise en œuvre. Si vous n’êtes pas d’accord, je vous exhorte à examiner chaque implémentation de getter et de getter avant de l’utiliser pour vérifier si ce n’est pas simplement une fève.

Answer 5

À première vue, il semble enfreindre le principe du moindre étonnement . Si je suis un utilisateur de votre classe, je m'attendrais à ce qu'un poseur fasse exactement ce que je lui dis. Je lève une exception dans le setter pour forcer les utilisateurs à rogner l'entrée.

L’autre (meilleure?) alternative consiste à changer le nom de la méthode en trimAndSetString. De cette façon, il n’est pas surprenant de réduire l’entrée.

Answer 6

Corrigez-moi si je me trompe, mais il me semble logique que le passeur tienne ce genre de logique. Si le sélecteur attribue simplement une valeur à une variable interne sans la vérifier, pourquoi ne pas exposer la variable elle-même?

Answer 7

C’est la raison pour laquelle vous utilisez des paramètres plutôt que d’exposer les champs d’objets au monde entier.

Soit une classe contenant un angle entier compris entre 0 et 359 inclus.

Si vous exposez le champ, les fonctions d’appel peuvent le définir comme bon leur semble, ce qui romprait le contrat spécifié par votre API. Cela risquerait également de casser vos fonctionnalités quelque part en bas de la piste car votre code est écrit pour supposer une certaine plage pour cette variable.

Avec un passeur, vous pouvez faire un certain nombre de choses. L'une consiste à déclencher une exception pour indiquer qu'une valeur non valide a été transmise, mais cela serait incorrect selon moi (dans ce cas). Cela sera probablement plus utile si vous modifiez la valeur d'entrée entre 0 et 359, comme avec:

actualVal = passedValue % 360;

Tant que cela est spécifié dans votre interface (API), cela est parfaitement valide. En fait, même si vous ne le spécifiez pas, vous êtes toujours libre de faire ce que vous voulez depuis que l'appelant a violé le contrat (en transmettant une valeur en dehors de la plage). J'ai tendance à suivre la règle de "désinfecter votre contribution dès que possible".

Dans votre cas, tant que vous spécifiez que la chaîne est stockée au format coupé, les appelants n'ont aucune raison de se plaindre (vous avez déjà indiqué qu'une telle chaîne est invalide). En termes de taille de code (et non de vitesse), il est préférable de le faire dans le programme de configuration plutôt que dans chaque morceau de code qui appelle le programme de configuration. Cela garantit également que la chaîne est stockée telle que vous l'attendez - il n'y a aucune garantie qu'un appelant ne stocke pas accidentellement (ou délibérément) une chaîne non coupée.

Answer 8

Oui. Une caractéristique de la conception orientée objet est que l’appelant peut traiter votre classe comme une boîte noire. Ce que vous faites à l'intérieur est votre propre entreprise, à condition que le comportement de l'interface soit documenté et logique.

Answer 9

Tandis que différentes personnes ont des philosophies différentes, je suggérerais que les régleurs de propriété ne soient appropriés que dans les cas où ils définiront un aspect de l'état de l'objet pour qu'il corresponde à la valeur indiquée et avertiront peut-être ceux qui se soucient du changement, mais ne le feront pas. sinon, cela affecte l'état de l'objet (il est tout à fait approprié qu'un ouvreur de propriétés modifie la valeur d'une propriété en lecture seule si cette propriété est définie en fonction de l'état associé à l'émetteur de propriétés; par exemple, La propriété Right en lecture seule d'un contrôle peut être définie en termes de Bounds ). Les gestionnaires de propriétés doivent lever une exception s’ils ne peuvent pas exécuter l’opération indiquée.

Si l'on souhaite autoriser un client à modifier l'état d'un objet d'une manière qui ne correspond pas à la description ci-dessus, il convient d'utiliser une méthode plutôt qu'une propriété. Si l'on appelle Foo.SetAngle (500) , on peut raisonnablement s'attendre à ce que la méthode utilise le paramètre indiqué pour définir l'angle, mais la propriété Angle peut ne pas renvoyer l'angle. sous la même forme que celle qui a été définie (par exemple, il pourrait en renvoyer 140). Par contre, si Angle est une propriété en lecture-écriture, on pourrait s’attendre à ce que l’écriture d’une valeur de 500 soit interdite, sinon la valeur soit lue 500. Si l’on voulait avoir l'objet stocke un angle compris entre 0 et 359, il peut également avoir une propriété en lecture seule appelée BaseAngle , qui renvoie toujours un angle sous cette forme.