Validation des données du constructeur

Question

Un exemple de classe dans le "Manuel de description de classe C#" (p. 137) n'appelle pas la méthode de validation des classes pour un champ spécifique à l'intérieur du constructeur des classes uniquement. Donc, fondamentalement, la classe d'échantillon vous permet de créer un objet avec de mauvaises données et ne lance une erreur que pour cette donnée lorsque vous appelez la propriété du champ qui la valide alors. Donc vous avez maintenant un mauvais objet et ne le savez pas après le fait.

Je n'ai jamais compris pourquoi ils n'appellent pas simplement la propriété du constructeur en lançant une erreur immédiatement si de mauvaises données sont trouvées pendant l'initialisation? Je les ai envoyé par e-mail en vain ...

J'ai tendance à utiliser le format suivant en appelant mes propriétés de mes constructeurs - est-ce la bonne structure pour valider les données d'initialisation? ty

class Foo 
{ 
    private string _emailAddress; 

    public Foo(string emailAddress) 
    { 
     EmailAddress = emailAddress; 
    } 

    public string EmailAddress 
    { 
     get { return _emailAddress; } 
     set 
     { 
      if (!ValidEmail(value)) 
       throw new ArgumentException 
        (string.Format 
        ("Email address {0} is in wrong format", 
        value)); 

      _emailAddress = value; 
     } 
    } 


    private static bool ValidEmail(string emailAddress) 
    { 
     return Regex.IsMatch 
      (emailAddress, @"\b[A-Z0-9._%+-]+" + 
          @"@[A-Z0-9.-]+\.[A-Z]{2,4}\b", 
          RegexOptions.IgnoreCase); 
    } 
} 

Answer 1

Eh bien, pour l'un, vous êtes susceptible d'obtenir le NullReferenceException redoutée, puisque vous n'êtes pas vérifier si emailAddress est nulle à tous les niveaux. Cette vérification particulière doit être effectuée dans le constructeur lui-même, et si emailAddress IS est nul, lancez une ArgumentNullException. Pour le reste, je ne vois pas de problèmes particuliers car il est écrit dans votre échantillon. Cependant, certains problèmes peuvent survenir si vous rendez la propriété virtuelle et dérivez des enfants de cette classe. L'ordre d'exécution de l'initialisation du champ, de la base et des consturceurs de classes dérivées devient alors un problème, et vous devez faire attention.

Answer 2

Je ne vois rien de mal à cette approche. Vous pouvez appeler des méthodes sur ceci dans le constructeur, et les setters/getters de propriété sont juste du sucre syntaxique pour les appels de méthode.

Answer 3

Oui, si votre approche générale est:

Assurez-vous que vous ne pouvez obtenir une instance d'un objet valid

je l'aime.

Constructors doit être utilisé pour créer des objets qui sont immédiatement valides, ne pas créer juste un « contenant », des choses à mettre en.

Answer 4

la validation se produit lorsque l'adresse e-mail est définie. C'est là que vous le voulez parce que l'adresse e-mail pourrait éventuellement être définie à nouveau plus tard.

Si vous appeliez également la validation dans le constructeur, vous effectueriez un appel de validation supplémentaire et redondant (une fois lorsqu'il est construit, un autre lorsque l'adresse e-mail est définie dans le constructeur).

Answer 5

Cela n'a aucun sens pour moi de ne pas valider les données dans le constructeur. Comme vous le faites remarquer, l'objet peut finir dans un état invalide. Compte tenu de cette conception, vous ne réaliseriez même pas que vous aviez de mauvaises données lors de l'appel du getter.

Pour tout ce qui est de complexité moyenne ou supérieure, j'ai tendance à utiliser une approche Broken Rules plutôt que de lancer immédiatement une exception. Dans cette approche, je définis un objet BrokenRules qui contient des informations sur la classe et la propriété qui ne sont pas valides et la raison pour laquelle il est invalide. Ensuite, dans une classe de base commune, je définis une liste pour contenir une liste de tout "faux" à propos de l'objet. Une propriété (encore une fois dans la classe de base) IsValid indique s'il existe actuellement des règles brisées.

L'avantage de ceci est qu'il pourrait y avoir plusieurs problèmes avec l'état de l'objet. Si un utilisateur est invité à corriger les problèmes (c.-à-d.cet objet est défini à partir d'une interface utilisateur), fournissant une liste de tous les problèmes permet à l'utilisateur de les corriger en une seule fois, plutôt que de fixer une erreur juste pour être informé qu'il y en a un autre. Et un autre. Etc