Ho letto il post The Flawed Theory Behind Unit Testing di Michael Feathers e mi ha fornito alcuni spunti interessanti di riflessione. In particolare:
John Nolan, gave his developers a challenge: write OO code with no getters. Whenever possible, tell another object to do something rather than ask. In the process of doing this, they noticed that their code became supple and easy to change.
Ho rivolto la questione al team con cui sto lavorando ed il coach ha posto la seguente domanda:
Una cosa che continuo a chiedermi a proposito dell "tell, don't ask" è la maniera in cui vengono normalmente realizzate le pagine web: tu hai un template a cui passi oggetti a cui chiedi varie informazioni. E' tutto un "ask, don't tell", che fa sì che gli oggetti che passi alla view siano, alla fine, oggetti di dominio, i quali finiscono per essere poco più che contenitori di dati estratti dal DB. Questo è quello che si fa di solito. La domanda che vi pongo è: come si potrebbe fare altrimenti? A partire dalla view: come puoi fare una view che applica il "tell, don't ask"?
Un altro link interessante su questo concetto è Tell, Don't Ask.
Alla domanda di prima non ho una risposta, ma ci sto riflettendo. Inoltre voglio approfondire l'argomento e verificare se l'approccio è efficace. Questo implica ragionare con gli oggetti in funzione di cosa fanno piuttosto che dipendere da quale stato siano.
In termini di TDD significa prediligere i test d'interazione piuttosto che quelli di stato e quindi l'utilizzo intensivo dei mock objects.
Cosa ne pensate?