Konstruktordaten validieren

Question

Eine Beispielklasse im "C# Class Desing Handbook" (S. 137) ruft die Klassenvalidierungsmethode für ein bestimmtes Feld nicht innerhalb des Konstruktors nur für Klassen auf. Die Beispielklasse ermöglicht es Ihnen also, ein Objekt mit ungültigen Daten zu erstellen und nur dann einen Fehler für diese Daten zu erzeugen, wenn Sie die Eigenschaft des Feldes aufrufen, die dann die Validierung durchführt. Du hast also ein schlechtes Objekt und weißt es erst nachher.

Ich habe nie verstanden, warum sie nicht einfach die Eigenschaft vom Konstruktor aufrufen und sofort einen Fehler auslösen, wenn während der Initialisierung fehlerhafte Daten gefunden werden? Ich habe sie ohne Erfolg gemailt ...

Ich neige dazu, das folgende Format zu verwenden, indem ich meine Eigenschaften von meinen Konstruktoren aufrufe - ist diese richtige Struktur, um Initialisierungsdaten zu validieren?

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

Nun, zum einen, sind Sie wahrscheinlich die gefürchtete Nullreferenceexception bekommen, da Sie nicht überprüft werden, ob emailaddress auf jeder Ebene null ist. Diese spezielle Überprüfung sollte im Konstruktor selbst durchgeführt werden, und wenn emailAddress NULL ist, eine ArgumentNullException werfen. Im übrigen sehe ich keine besonderen Probleme damit, wie es in Ihrer Probe steht. Es gibt jedoch einige Probleme, die auftreten können, wenn Sie die Eigenschaft virtuell machen und untergeordnete Elemente aus dieser Klasse ableiten. Die Ausführungsreihenfolge von Feldinitialisierung, Basis- und abgeleiteten Klassenkonstruktoren wird dann zu einem Problem, und Sie müssen vorsichtig sein.

Answer 2

Ich sehe nichts falsch mit diesem Ansatz. Sie können Methoden dazu im Konstruktor aufrufen, und Property-Setter/Getter sind nur syntaktische Zucker für Methodenaufrufe.

Answer 3

Ja, wenn Ihr allgemeiner Ansatz ist:

Stellen Sie sicher, dass Sie nur eine Instanz ein valid Objekt bekommen können

dann habe ich es lieben.

Konstrukteurs sollten Objekte verwendet werden, zu erstellen, die sofort gültig sind, nicht nur einen ‚Container‘ zu schaffen, für die Dinge in gestellt werden.

Answer 4

die Validierung geschieht, wenn die E-Mail-Adresse eingestellt ist. Dies ist, wo Sie es wollen, weil die E-Mail-Adresse möglicherweise später wieder eingestellt werden kann.

Wenn Sie im Konstruktor auch Validierung aufgerufen haben, würden Sie einen zusätzlichen, redundanten Überprüfungsaufruf durchführen (einmal beim Erstellen, ein anderer, wenn die E-Mail-Adresse im Konstruktor festgelegt ist).

Answer 5

Es macht keinen Sinn, Daten im Konstruktor nicht zu validieren. Wie Sie darauf hinweisen, kann das Objekt in einem ungültigen Zustand enden. Angesichts dieses Designs würden Sie nicht einmal bemerken, dass Sie schlechte Daten hatten, wenn Sie den Getter aufrufen.

Für etwas moderater Komplexität oder höher tendiere ich dazu, einen Broken Rules-Ansatz zu verwenden, anstatt sofort eine Exception auszulösen. In diesem Ansatz definiere ich ein BrokenRules-Objekt, das Informationen über die Klasse und Eigenschaft enthält, die ungültig ist, und den Grund, dass sie ungültig ist. Dann definiere ich in einer gemeinsamen Basisklasse eine Liste, um eine Liste von allem "Falschen" über das Objekt aufzunehmen. Eine Eigenschaft (wiederum in der Basisklasse) IsValid gibt an, ob es momentan irgendwelche gebrochenen Regeln gibt.

Der Vorteil davon ist, dass möglicherweise mehrere Dinge mit dem Objektstatus falsch sind. Wenn ein Benutzer aufgefordert wird, die Probleme zu beheben (z.Dieses Objekt wird von einer Benutzerschnittstelle aus eingestellt, wobei eine Liste aller Probleme zur Verfügung gestellt wird, die der Benutzer in einem Schritt korrigieren kann, anstatt einen Fehler zu beheben, nur um zu erfahren, dass es einen anderen gibt. Und noch einer. Etc.