Ich frage mich, ob es eine gute Idee ist Prüfungen in Getter und Setter oder an anderer Stelle im Code zu machen.Datenüberprüfungen in Getter/Setter oder anderswo?
Dies könnte Sie überraschen, wenn es um Optimierungen kommt und auf den Code zu beschleunigen, ich glaube, Sie sollten nicht Prüfungen in Getter und Setter, aber in dem Code, wo Sie Aktualisierung Ihre Dateien sind oder Datenbank. Liege ich falsch?
Nun, einer der Gründe, warum Klassen in der Regel private Mitglieder mit öffentlichen Getter/Setter enthalten, ist genau, weil sie Daten verifizieren können.
Wenn Sie eine Zahl haben, die zwischen 1 und 100 liegen kann, würde ich definitiv etwas in den Setter setzen, das dies validiert und dann vielleicht eine Ausnahme auslöst, die vom Code abgefangen wird. Der Grund ist einfach: Wenn Sie es nicht im Setter machen, müssen Sie sich daran erinnern, dass jedes Mal, wenn Sie es einstellen, 1 bis 100 Limitierung auftritt, was zu doppeltem Code führt oder wenn Sie es vergessen, führt es zu einem ungültigen Zustand.
Was die Leistung, ich bin mit Knuth hier:
„Wir über kleine Effizienz vergessen sollte, sagen wir etwa 97% der Zeit. Vorzeitige Optimierung ist die Wurzel allen Übels“
Die Validierung sollte in einer Validierungsmethode getrennt von Getter oder Setter erfasst werden. Auf diese Weise ist die Validierung verfügbar, wenn die Validierung für mehrere Komponenten wiederverwendet werden muss.
Wenn der Setter aufgerufen wird, sollte ein solcher Validierungsdienst verwendet werden, um Eingaben in das Objekt zu bereinigen. Auf diese Weise wissen Sie, dass alle in einem Objekt gespeicherten Informationen zu jeder Zeit gültig sind.
Sie benötigen keine Validierung für den Getter, da Informationen über das Objekt bereits als gültig anerkannt werden.
Speichern Sie Ihre Validierung erst nach einem Datenbankupdate !! Es ist besser zu fail schnell.
Aus der Perspektive der am besten wartbaren Code, denke ich, dass Sie so viel Validierung wie Sie können in der Setter einer Eigenschaft tun. Auf diese Weise werden Sie keine ungültigen Daten cachen oder anderweitig damit umgehen.
Schließlich sind dies Eigenschaften, für die Eigenschaften bestimmt sind. Wenn alles, was Sie haben eine Reihe von Eigenschaften wie ist ...
public string Name
{
get
{
return _name;
}
set
{
_name = value;
}
}
... sie könnten auch Felder sein
Es hängt davon ab.
Im Allgemeinen sollte Code schnell fehlschlagen. Wenn der Wert durch mehrere Punkte im Code festgelegt werden kann und Sie erst nach dem Abrufen des Werts validiert werden, scheint der Fehler im Code enthalten zu sein, der die Aktualisierung durchführt. Wenn die Setter die Eingabe validieren, wissen Sie, welcher Code versucht, ungültige Werte festzulegen.
Vielleicht möchten Sie überprüfen Domain Driven Design, von Eric Evans.DDD hat diesen Begriff einer Spezifikation:
... explizite Prädikat-wie VALUE OBJECTS für spezialisierte Zwecke. A SPECIFICATION ist ein Prädikat, das bestimmt, ob ein Objekt erfüllt oder nicht erfüllt einige Kriterien.
Ich glaube, schnell zu scheitern ist eine Sache, die andere ist, wo die Logik für die Validierung zu halten. Die Domain ist der richtige Ort, um die Logik zu behalten, und ich denke, ein Specification-Objekt oder eine Validierungsmethode für Ihre Domain-Objekte wäre ein guter Platz.
Ich möchte IDataErrorInfo implementieren und meine Validierungslogik in seine Fehler und diese [columnName] Eigenschaften setzen. Auf diese Weise können Sie, wenn Sie programmgesteuert prüfen möchten, ob ein Fehler vorliegt, eine dieser Eigenschaften im Code testen oder die Validierung in Web Forms, Windows Forms oder WPF an die Datenbindung übergeben.
Die Bindungseigenschaft "ValidatesOnDataError" von WPF macht dies besonders einfach.
@Terrapin, re:
Wenn alles, was Sie haben, ist ein Bündel von [simple öffentlichen set/get] Eigenschaften ... sie könnte genauso gut sein Feld
Eigenschaften haben andere Vorteile gegenüber Feldern. Sie sind ein expliziter Vertrag, sie sind serialisiert, sie können später debuggt werden, sie sind ein schöner Ort für die Erweiterung durch Vererbung. Die Clunkier-Syntax ist eine zufällige Komplexität - dies wird beispielsweise durch .NET 3.5 behoben.
Eine gängige (und fehlerhafte) Übung besteht darin, mit öffentlichen Feldern zu beginnen und sie später auf "Bedarf" in Eigenschaften umzuwandeln. Dies bricht Ihren Vertrag mit jedem, der Ihre Klasse konsumiert, also ist es am besten, mit Eigenschaften zu beginnen.
Ich versuche, meine Objekte niemals in einen ungültigen Zustand zu bringen, daher hätten Setter definitiv eine Validierung sowie alle Methoden, die den Status ändern. Auf diese Weise muss ich nie befürchten, dass das Objekt, mit dem ich es zu tun habe, ungültig ist. Wenn Sie Ihre Methoden als Validierungsgrenzen beibehalten, müssen Sie sich nie um Validierungs-Frameworks und IsValid() - Methodenaufrufe sorgen, die überall verstreut sind.
Könnten Sie näher ausführen? Wollen Sie zum Beispiel nach <5 && > 0 in einer separaten Validierungsmethode suchen? Was genau machen dann Ihre Getter und Setter, die ein reguläres Feld nicht tut? –