Perché non ci sono parametri migliori dei pochi metodi di parametro?

La mia comprensione della richiesta dello zio Bob è: pensa attentamente al ciclo di vita dei tuoi oggetti.

Per quanto mi riguarda ho scoperto che abbastanza spesso posso trasformare alcuni parametri del metodo in parametri costruttore, poiché non cambiano durante l'uso dell'oggetto.

Al contrario di Uncle Bobs non trovo i metodi nessun parametro superiori. Questo perché i miei metodi spesso creano un valore di ritorno che viene utilizzato nel metodo successivo. L'aggiunta di tale valore di ritorno allo stato degli oggetti invece di passarla come parametro al metodo successivo diminuisce la leggibilità perché nasconde una dipendenza tra questi metodi. Questo diventa anche un problema quando si applicano i refactoring automatico move method degli IDE che rende accessibile la variabile membro (temporanea) per l'oggetto il metodo spostato in ...

Inoltre apre la possibilità di cambiare l'ordine dei metodi in modo errato. La versione "senza stato" genererebbe un errore del compilatore in questo caso ...

Il consiglio dello zio Bob dovrebbe essere preso con un granello di sale. È sempre importante comprendere il contesto per i consigli e i trade-off coinvolti.

Bob è un sostenitore del paradigma orientato agli oggetti. La premessa di fondo è che vuoi seguire il paradigma OO. Se preferisci uno stile funzionale o una via di mezzo pragmatica, il suo consiglio potrebbe non essere adatto a te.

Se ti capisco correttamente, preferisci testare i metodi singolarmente. Questo è molto più semplice se c'è meno dipendenza dallo stato dell'oggetto e più dai parametri. Le funzioni libere senza effetti collaterali sono particolarmente facili da testare. Ma questo è uno stile funzionale. In stile OO, la "unità" è l'oggetto, non il metodo. Non testare un singolo metodo separatamente, si verifica sempre il comportamento di un oggetto.

Quando dici che i metodi con un numero minore di parametri sono più accoppiati, presumo tu intenda più accoppiati allo stato dell'oggetto e altri metodi sullo stesso oggetto? Questo non è necessariamente un aspetto negativo in OO - piuttosto cerchi di ottenere un accoppiamento basso tra gli oggetti e un'elevata coesione per l'oggetto.

Non penso che nessuno abbia dimostrato che un paradigma è superiore a un altro, quindi tutto ciò si riduce all'opinione (o alla religione). Ma se accetti la premessa per cui vuoi sforzarti per una pura architettura OO, allora il consiglio di Bob ha senso.

Nello stile di codifica di Uncle Bob, ci sono molti piccoli metodi con nomi descrittivi che non prendono alcun parametro ma sono lì solo per strutturare il codice per il lettore. Solitamente non testare unitamente questi metodi direttamente, ma attraverso metodi di livello superiore di una classe. Non fare l'errore di pensare che devi avere un metodo di prova corrispondente per ogni metodo nella classe sotto test.

In secondo luogo, come affermato correttamente nei commenti, i metodi senza parametri sanno ancora tutto dello stato interno della classe, hanno il parametro questo di impleicit. Il test del comportamento di un metodo dipende quindi dai parametri e dallo stato dell'oggetto circostante. Se non si hanno parametri, questo è in realtà uno stato inferiore a cui pensare quando si prova un metodo. Io chiamo un metodo da un test, lo configuri modificando lo stato dell'oggetto. Se ci fossero dei parametri, questo sarebbe uno spazio di stato ancora più grande per i tuoi test da coprire, quindi tecnicamente potresti dire che avere zero argomenti è il caso migliore.

Detto questo, alla fine dipende ancora dal tuo codice reale se è facile da testare. Supponi di avere una funzione f(int a) con un parametro. Puoi sempre rendere int a un campo della classe e la funzione f() ora ha zero parametri. Ciò non renderebbe più facile o difficile testare.