Nel post precedente abbiamo visto come “addurre scuse plausibili” (cit.) per introdurre il concetto di factory all’interno del nostro domain model, come unico entry point per la creazione (e setup iniziale) dei nostri aggregate root.
Ci eravamo lasciati con l’idea di rendere più parlanti non solo i metodi di creazione, ma anche i parametri degli stessi, cercando di virare, perchè no, verso un DSL-light, con poco sforzo, che possa aumentare la leggibilità del codice. Per intenderci, passare da:
a qualcosa del tipo:
Direi molto, ma molto meglio…che dite?
Sfruttando alcune funzionalità “nascoste” (nel senso di poco, ma poco, utilizzate) di c#, il comportamento è facilmente raggiungibile. Innanzitutto, dobbiamo oscurare il costruttore del nostro aggregate root, in modo che nessun altro, oltre alla factory, abbia la possibilità di istanziare il nostro oggetto.
Niente di più facile, ma ora come è possibile “abilitare” la factory alla costruzione dell’oggetto? Rendendo il costruttore “internal” permettendo a tutti gli altri componenti dello stesso assembly di potervi accedere? E se usassimo le nested class?
Aggregate root e factory, per come li abbiamo definiti, vanno veramente a braccetto, entrambi fanno parte del modello e uno non ha senso di esistere senza l’altro. Quindi non lo vedo come un male che uno (la factory) abbia la possibilità di accedere ai membri nascosti dell’altro (aggregate root) per poterne fare il setup…è quello che ci serve in fin dei conti.
Se poi utilizzassimo anche la keyword partial, potremmo tranquillamente “pulire” anche il layout del file, splittando aggregate root e factory su due file differenti.
Ora dobbiamo fare in modo di poter utilizzare la sintassi fluent nel metodo della factory. Creiamo un po’ di codice, poco di concetto, ma molto utile ai fini dell’obbiettivo 🙂
il più è fatto, e con poco sforzo la factory cambia nel modo seguente:
Obbiettivo centrato. Poco sforzo, massimo risultato. Ben fatto!
