DDD e uso di getter e setter

Question

Ho letto alcuni articoli/post riguardanti l'uso di getter e setter e come aiutano a sconfiggere lo scopo dell'incapsulamento negli oggetti del modello di dominio. Comprendo la logica alla base del non utilizzo dei setter: si consente al codice client di manipolare gli attributi di tale oggetto, al di fuori del contesto delle regole e degli invarianti di business dell'oggetto.

Ora questo principale mi confonde ancora. Ad esempio, cosa succede se ho bisogno di cambiare il valore di una variabile membro di un oggetto? Ad esempio, se il nome di una persona cambia come posso rifletterlo nel modello? All'inizio ho pensato, beh, perché non ho una funzione chiamata 'ChangeName' che mi permette di passare il nuovo nome e che a sua volta può cambiare la variabile 'name' interna. Beh ... questo è solo un setter, non è vero?

Che cosa ho bisogno di chiarire - se dovessi eliminare completamente i setter, quindi in situazioni come quella di cui sopra, dovrei fare affidamento esclusivamente sui parametri del costruttore? Devo passare il nuovo valore dell'attributo al posto del vecchio valore dell'attributo tramite un costruttore, dopo di che posso mantenere le modifiche passando l'oggetto a qualsiasi infrastruttura di persistenza che dispongo?

Questi due articoli sono utili in questa discussione:

1. http://kellabyte.com/tag/ddd/
2. http://typicalprogrammer.com/?p=23

Answer 1

Bene, questa è una discussione classica. Ci sono molti altri thread qui in Stack Overflow su questo.

Ma. Get/Set (Auto Properties?) Non sono tutti male. Ma tendono a costringerti a costruire le tue entità come contenitori di dati "morti" che hanno solo metodi e non metodi. I segni di questo è spesso chiamato dominio anemico e hanno un comportamento molto piccolo. La mia raccomandazione è:

1. Cerca di usare il prop il meno possibile.
2. Prova a trovare gruppi di dati che appartengono insieme e DOVREBBE essere insieme come ex. NomeComeNome e Cognome. Un altro esempio è codice postale, città, via. Questi dati sono meglio impostare tramite un metodo . Riduce al minimo le possibilità che la tua entità non sia valida.
3. Spesso i dati che appartengono insieme possono essere raggruppati come oggetti Valore .
4. Altri oggetti valore tendono a far emergere metodi più descrittivi dall'entità che sono "Verbi" anziché le solite "Nomi" entità.
5. Altri metodi per gli oggetti valore si aprono anche per aggiungere altro comportamento e magari ridurre i servizi "Fat" (forse non si dispone di servizi con troppa logica aziendale trapelata ...).

C'è altro da dire qui ... ma una risposta breve. Informazioni sull'impostazione dei dati nel costruttore: lo faccio solo se questa entità non può "vivere"/esistere senza quei dati. Per la persona entità direi che il nome forse non è quel tipo di importante. Ma il numero di previdenza sociale può essere un candidato per i dati del costruttore. Oppure il Dipendente dell'entità deve avere un'azienda nel costruttore, semplicemente perché un dipendente deve appartenere a un'azienda.