[pugMI] Factory coese e testabili

[Giorgio Sironi]

2013/4/12 Jacopo Romei <jromei a gmail.com>

> 1. Una factory si occupa di prepararmi un oggetto a seconda delle
> condizioni di contesto.
>

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.


> 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.
>

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.
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.


> 3. Un sano principio di testabilità, però, ci porta a voler garantire la
> 'sostituibilità' degli stessi componenti necessari alla costruzione dei
> prodotti della factory.
>

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.


> 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.
>

Una bella sfilza di new(), closures, e campi privati per riciclare gli
oggetti

>
> 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?
>

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).


-- 
Giorgio Sironi (@giorgiosironi)
http://giorgiosironi.com <http://giorgiosironi.blogspot.com/>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://ml.grusp.org/pipermail/milano-grusp.org/attachments/20130413/87373921/attachment-0001.htm>