<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">2013/4/12 Jacopo Romei <span dir="ltr"><<a href="mailto:jromei@gmail.com" target="_blank">jromei@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div><div><div><div><div><div>1. Una factory si occupa di prepararmi un oggetto a seconda delle condizioni di contesto.<br></div></div></div></div></div></div></div></blockquote><div><br></div><div style>Per contesto, intendo la configurazione corrente dell'applicazione come gli URL da chiamare o la password del database; a volte alcuni parametri provenienti la richiesta come la chiave da usare per criptare il risultato di un'operazione.</div>

<div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div></div></div>2.
 Un factory quindi se ne assume la responsabilità e in base al principio
 "tell don't ask" non deve mostrare troppe sue pudenda, quindi non deve,
 in virtù del principio suddetto, ricevere le dipendenze necessarie ai 
suoi prodotti finiti.<br></div></div></div></div></div></blockquote><div><br></div><div style>Per le Factory che creano oggetti il cui ciclo di vita è lungo quanto l'applicazione (Application, i Controller/Action), credo di sì. Per le Factory che creano oggetti che vivono meno, potrebbero richiedere come dipendenza oggetti dal ciclo di vita più lungo.</div>

<div style>Ad esempio se dovrò creare degli oggetti Taxi durante la richiesta (e come li devo creare dipende da un parametro passato in GET), avrò una TaxiFactory come collaboratore del Controller che viene costruita con ad esempio la connessione al database. Gliela devo passare perché se no ne deve aprire un'altra da sola, invece che usare la stessa del resto dell'applicazione.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div></div>3. Un sano principio di testabilità, 
però, ci porta a voler garantire la 'sostituibilità' degli stessi 
componenti necessari alla costruzione dei prodotti della factory.<br></div></div></div></div></blockquote><div><br></div><div style>Un principio di unit-testabilità; se testi a livello end-to-end non è solitamente necessario sostituire gli oggetti perché basta la configurazione (e.g. password di MySQL, host di MongoDB). Anzi, i miei end-to-end test devono usare gli stessi oggetti della versione di produzione, se no sto testando un'altra cosa rispetto a quella che andrà online.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div></div>4.
 La factory, inoltre, è uno di quei pattern che servono a incapsulare 
una zona di contatto del nostro sistema con il mondo 'sporco e infetto 
là fuori' e - per esempio - necessariamente dovrà aggregare, montare, 
istanziare esplicitamente, dipendere in modo 'hardcoded' da altre 
classi.<br></div></div></div></blockquote><div><br></div><div style>Una bella sfilza di new(), closures, e campi privati per riciclare gli oggetti </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div><div><br></div>La domanda è, tutto considerato: posso sacrificare 
parte della testabilità della factory come *unità* disaccoppiata dal 
resto in favore di un test più d''integrazione' che però mi permetta di 
sviluppare factory più coese?<br></div></div></blockquote><div><br></div><div style>Se per coeso intendi "tengo quello che cambia insieme in un punto solo", direi di sì: in nome della coesione ho costruito oggetti che implementavano due interfacce molto separate (come HttpController e ElencoDelTelefono).</div>

</div><br clear="all"><div><br></div>-- <br>Giorgio Sironi (@giorgiosironi)<div><a href="http://giorgiosironi.blogspot.com/" target="_blank">http://giorgiosironi.com</a></div>
</div></div>