Verwendung der wiederverwendbaren Validierung in einem ValueObject

Ich versuche, einige Techniken zu kombinieren.

Es scheint eine gute Übung zu sein, niemals ein ValueObject zu erstellen, das nicht gültig ist. Der ValueObject-Konstruktor sollte daher fehlschlagen, wenn der bereitgestellte Inhalt nicht gut genug ist, um ein gültiges ValueObject zu erstellen. In den Beispielen, die ich habe, kann ein EmailAddress-Objekt nur erstellt werden, wenn ein Wert vorhanden ist. So weit, so gut.

Wenn ich den Wert der angegebenen E-Mail-Adresse überprüfe, beginne ich, an den Prinzipien zu zweifeln. Ich habe vier Beispiele, aber ich kann nicht sagen, welches als die beste Praxis angesehen werden sollte.

Beispiel 1 ist das einfache: einfach eine Konstruktfunktion, ein erforderlicher Parameter "value" und eine separate Funktion validieren, um den Code sauber zu halten. Der gesamte Validierungscode bleibt innerhalb der Klasse und wird niemals für die Außenwelt verfügbar sein. Die Klasse hat nur einen Zweck: Speichere die E-Mail-Adresse und vergewissere dich, dass sie niemals ungültig ist. Aber der Code wird niemals wiederverwendbar sein - ich erschaffe ein Objekt damit, aber das ist alles.

Beispiel 2 macht die Validierungsfunktion zu einer statischen Funktion. Die Funktion wird niemals den Status der Klasse ändern, daher ist es eine korrekte Verwendung des statischen Schlüsselworts, und der darin enthaltene Code wird niemals in der Lage sein, irgendetwas zu irgendeiner Instanz zu ändern, die aus der Klasse erzeugt wird, die die statische Funktion einbettet. Aber wenn ich den Code wiederverwenden möchte, kann ich die statische Funktion aufrufen. Trotzdem fühlt sich das für mich dreckig an.

Beispiel 3 führt eine andere Klasse ein, die innerhalb des Körpers meines Objekts fest codiert ist. Die andere Klasse ist eine Validierungsklasse, die den Validierungscode enthält, und erstellt somit eine Klasse, die immer und überall verwendet werden kann, wo ich eine Validierungsklasse benötige. Die Klasse selbst ist fest codiert, was auch bedeutet, dass ich eine Abhängigkeit von dieser Validierungsklasse erzeuge, die immer in der Nähe sein sollte und nicht durch die Abhängigkeitsinjektion injiziert wird. Man könnte sagen, dass ein fest codierter Validator genauso schlecht ist wie der vollständige Code im Objekt, aber andererseits: DI ist wichtig, und auf diese Weise muss man eine neue Klasse erstellen (erweitern oder einfach umschreiben) Ändere einfach die Abhängigkeit.

Beispiel 4 verwendet die validator-Klasse erneut, setzt sie jedoch in den Konstruktor. Mein ValueObject benötigt daher eine Validator-Klasse, die bereits vorhanden und erstellt ist, bevor die Klasse erstellt wird, aber es ist möglich, den Validator einfach zu überschreiben. Aber wie gut ist es für eine einfache ValueObject-Klasse, eine solche Abhängigkeit im Konstruktor zu haben, da die einzige Sache, die wirklich wichtig ist, der Wert ist, sollte es nicht meine Sorge sein, zu wissen, wie und wo zu handhaben ist, wenn die E-Mail korrekt ist ein korrekter Validator.

Das letzte Beispiel, über das ich nachgedacht habe, stellt einen Standard-Validator dar und ermöglicht es mittlerweile, über DI ein Überschreiben für den Validator im Konstruktor zu injizieren. Aber ich begann zu zweifeln, wie gut ein einfaches ValueObject ist, wenn man den wichtigsten Teil überschreibt: die Validierung.

Also, jeder hat eine Antwort, wie man diese Klasse am besten schreiben sollte, das ist richtig für etwas so einfaches wie eine E-Mail-Adresse, oder etwas Komplexeres wie ein Barcode oder eine Visa-Karte oder was auch immer man denken mag. t verletzen DDD, DI, OOP, TROCKEN, falsche Verwendung von statisch, und so weiter ...

Der vollständige Code: