Guideline Google: iniettare collaboratori, passare i dati per chiamata

Per impostare gli input degli oggetti senza ambiguità, Google propone una regola semplice: “Construct with Collaborators, Call with Work”¹.

Sul blog Testing di Google, Shahar Roth presenta la linea guida, adattata da un episodio di Google Tech on the Toilet. L’idea chiave: distinguere tra due categorie di input. Da un lato i “collaboratori”, cioè le dipendenze stabili che definiscono l’identità dell’oggetto e lo accompagnano per tutta la sua vita. Dall’altro il “work”, gli input che variano a ogni interazione. I primi si passano al costruttore. I secondi si forniscono ai metodi, al momento della chiamata¹.

Così si evita di confondere ciò che l’oggetto è con ciò che l’oggetto fa in una data esecuzione. Se una dipendenza resta costante e caratterizza il comportamento continuativo dell’oggetto, rientra tra i collaboratori e si inietta nel costruttore. Se un input riguarda l’operazione corrente e cambia chiamata dopo chiamata, appartiene al “work” e si passa al metodo che esegue quell’operazione¹.

Le fonti offrono esempi concreti di “work”: un percorso di file o una query al database. Entrambi variano a seconda del compito da svolgere e quindi non vanno nel costruttore. Si forniscono invece alla singola invocazione del metodo che li usa. Al contrario, i collaboratori non dipendono dalla specifica richiesta in ingresso; restano invariati una volta configurato l’oggetto¹.

La regola non introduce astrazioni nuove, ma rende esplicita una decisione di progettazione ricorrente: separare dipendenze stabili e dati per-call. Il costruttore rimane il punto in cui si definiscono le capacità persistenti dell’oggetto tramite i collaboratori. I metodi ricevono solo ciò che serve per completare l’azione richiesta in quel momento. La chiarezza della firma dei metodi migliora. Anche l’intento del costruttore diventa leggibile a colpo d’occhio.

Il post segnala l’origine del materiale nell’episodio di Google Tech on the Toilet e accredita l’autore. Dalla pagina è disponibile anche una versione pronta per la stampa dell’episodio, utile per la condivisione interna dei team¹.

Un’indicazione pratica emerge dalle stesse formule della linea guida. Quando ti chiedi dove posare un parametro, verifica due cose: definisce l’identità dell’oggetto nel tempo o descrive il lavoro di adesso? Se vale la prima, tratta quel parametro come un collaboratore e passalo al costruttore. Se vale la seconda, passalo al metodo che esegue il lavoro. Questa domanda binaria riduce l’ambiguità nelle API e limita scelte arbitrarie nella firma delle classi¹.