Datenüberprüfungen in Getter / Setter oder anderswo?

Nun, einer der Gründe, warum Klassen normalerweise 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 das 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 setzen, 1 zu 100 Limitierung ist, was zu doppeltem Code führt oder wenn Sie es vergessen, führt es zu einem ungültigen Zustand / p>

Was die Performance anbelangt, bin ich hier bei Knuth:

  

"Wir sollten kleine Wirkungsgrade vergessen, sagen wir etwa 97% der Zeit: vorzeitige Optimierung ist die Wurzel allen Übels."

@Terrapin, re:

  

Wenn alles was du hast ist ein Haufen [einfach   public set / get] Eigenschaften ... sie   könnte auch Felder sein

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) Praxis besteht darin, mit öffentlichen Feldern zu beginnen und sie später auf der Basis "nach Bedarf" in Eigenschaften umzuwandeln. Dies bricht Ihren Vertrag mit jedem, der Ihre Klasse konsumiert. Daher empfiehlt es sich, mit den Eigenschaften zu beginnen.

Kommt darauf an.

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.

Aus der Perspektive, den am besten wartbaren Code zu haben, denke ich, dass Sie so viel Validierung wie möglich im Setter einer Eigenschaft vornehmen sollten. Auf diese Weise werden Sie nicht im Cache gespeichert oder anderweitig mit ungültigen Daten umgehen.

Denn dafür sind Eigenschaften bestimmt. Wenn alles, was Sie haben, ist eine Reihe von Eigenschaften wie ...

... sie könnten auch Felder sein

Vielleicht möchten Sie Domain Driven Design von Eric Evans ausprobieren. DDD hat diese Vorstellung von einer Spezifikation:

  

... explizite Prädikat-ähnliche WERT   OBJEKTE für spezielle Zwecke. EIN   Spezifikation ist ein Prädikat, dass   bestimmt, ob ein Objekt das tut oder tut   nicht einige Kriterien erfüllen.

Ich denke, dass schnelles Scheitern die eine Sache ist, die andere ist, wo die Logik für die Validierung bleibt. 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 Ort.

Die Validierung sollte getrennt von Getter oder Setter in einer Validierungsmethode erfasst werden. Wenn die Validierung über mehrere Komponenten hinweg wiederverwendet werden muss, ist sie verfügbar.

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 jederzeit gültig sind.

Sie benötigen keinerlei Validierung für den Getter, da die Informationen über das Objekt bereits als gültig gelten.

Speichern Sie Ihre Validierung erst nach einem Update der Datenbank !! Es ist besser, schnell zu scheitern .

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 über Validierungsframeworks und IsValid () - Methodenaufrufe sorgen, die überall verstreut sind.