DDD und die Verwendung von Getters und Setter

Question

DDD und die Verwendung von Getters und Setter

8

Ich habe ein paar Artikel / Beiträge zur Verwendung von Getters und Setter gelesen und wie sie dazu beitragen, den Zweck der Kapselung in Domänenmodellobjekten zu überwinden. Ich verstehe die Logik dahinter, keine Setter zu verwenden - Sie erlauben dem Client-Code, Attribute dieses Objekts außerhalb des Kontextes der Geschäftsregeln und Invarianten des Objekts zu manipulieren.

Jetzt verwirrt mich dieses Prinzip noch immer. Was passiert zum Beispiel, wenn ich den Wert einer Elementvariablen eines Objekts ändern muss? Wenn beispielsweise der Name einer Person geändert wird, wie kann ich dies im Modell widerspiegeln? Zuerst dachte ich, warum sollte ich nicht eine Funktion namens 'ChangeName' haben, mit der ich den neuen Namen weitergeben kann und dieser wiederum die interne Variable 'name' ändern kann. Nun .... das ist nur ein Setter, nicht wahr?

Was ich klären muss - wenn ich Setter komplett eliminieren würde, soll ich mich dann in Situationen wie dem oben genannten nur auf Konstruktorparameter verlassen? Sollte ich den neuen Attributwert anstelle des alten Attributwerts über einen Konstruktor übergeben, nach dem ich die Änderungen persistieren kann, indem ich das Objekt an die vorhandene Persistenzinfrastruktur übergebe?

Diese zwei Artikel sind in dieser Diskussion nützlich:

domain-driven-design getter-setter getter encapsulation setter

Chris 28.11.2011, 03:13

quelle

1 Antwort

Tags und Links domain-driven-design getter-setter getter encapsulation setter

Django: Verwenden von Annotate, Count und Distinct in einem Queryset LINQ Lambda - int in Zeichenfolge konvertieren

score 6 · Accepted Answer

Nun, das ist eine klassische Diskussion. Es gibt hier in Stack Overflow mehrere andere Threads.

Aber. Get / Set (Auto Eigenschaften?) Sind nicht alle schlecht. Sie neigen jedoch dazu, Ihre Entitäten als "tote" Datencontainer zu konstruieren, die nur Prop-Methoden und keine Methoden haben. Die Anzeichen dafür werden oft Anemic Domain genannt - und haben sehr wenig Verhalten. Meine Empfehlung ist:

Versuchen Sie, so wenig wie möglich Prop zu verwenden.
Versuchen Sie, Datengruppen zu finden, die zusammen gehören und SOLL sein sollten zusammen wie ex. Vorname Middename und Nachname. Ein anderes Beispiel ist Postleitzahl, Stadt, Straße. Diese Daten sind besser durch a einzustellen Methode. Es minimiert die Wahrscheinlichkeit, dass Ihre Entität ungültig ist.
Oft können Daten, die zusammen gehören, als Wert gruppiert werden Objekt.
Mehr Value-Objekte neigen dazu, aussagekräftigere Methoden hervorzubringen von deiner Entität, die "Verben" anstatt deiner normalerweise "Substantive" sind Entitäten.
Weitere Methoden für Ihre Wertobjekte öffnen sich auch, um mehr hinzuzufügen Verhalten und vielleicht reduzieren Sie Ihre "fetten" Dienste (vielleicht nicht haben Dienstleistungen mit zu viel durchgesickerte Geschäftslogik ...).

Hier gibt es mehr zu sagen ... aber eine kurze Antwort. Über das Setzen von Daten im Konstruktor: Das mache ich nur, wenn diese Entity ohne diese Daten nicht "leben" / existieren kann. Für Entitätsperson würde ich sagen, dass Name vielleicht nicht so wichtig ist. Aber Sozialversicherungsnummer kann ein Kandidat für Konstruktordaten sein. Oder Entität Mitarbeiter muss Firma im Konstruktor haben, einfach weil ein Mitarbeiter zu einer Firma gehört.