Testabile del codice Java: usando i fagioli modello con un costruttore

Question

Secondo Misko Hevery che ha un blog verificabilità. Gli sviluppatori dovrebbero evitare di 'titolare', 'contesto', e oggetti 'lavello' (queste hanno ogni sorta di altri oggetti e sono un grab bag di collaboratori). Passare l'oggetto specifico è necessario come parametro, invece di un titolare di tale oggetto.

Nell'esempio colpo, è questo codice odore? Dovrei passare solo i parametri che sono necessari o un modello / di fagioli con i dati che ho bisogno.

Per esempio, vorresti fare qualcosa di simile: Nota. Probabilmente potuto passare i dati come args costruttore. Si tratta di un odore di codice?

public Parser {
  private final SourceCodeBean source;

  public Parser(final SourceCodeBean s) {
    this.source = s;
  }

  public void parse() {
     // Only access the source field
     this.source.getFilename();
     ...
     ... assume that the classes uses fields from this.source
     ...
  }

}

public SourceCodeBean {
   private String filename;
   private String developer;
   private String lines;
   private String format;

   ...
   ...
   <ONLY SETTERS AND GETTERS>
   ...
}

...

Or 

public Parser {


  public Parser(String filename, String developer, String lines ...) {
    ...
  }

}

And building a test case

public void test() {
  SourceCodeBean bean = new SourceCodeBean():
  bean.setFilename();

  new Parser().parse();
}

Un'altra domanda: Con la scrittura di codice testabile, Tendi a scrivere troppe classi. E 'sbagliato avere troppe classi o una classe con troppi metodi. Le classi sono utili e hanno un unico scopo. Ma, ho potuto vedere dove potrebbero essere riscritta in una classe più grande ... ma questa classe avrebbe molteplici scopi.

Answer 1

Si noterà anche che Misko Hevery consiglia di parametri del gruppo di classi, ogni volta che il conteggio dei parametri aumenta o nei casi in cui questo è logicamente accettabile.

Quindi nel tuo caso, è possibile passare il SourceCodeBean senza rimorso.

Answer 2

Un sacco di quello che chiedete è altamente soggettiva, ed è difficile dare suggerimenti utili senza conoscere la piena portata di ciò che si sta cercando di realizzare, ma qui sono i miei 2 centesimi.

Vorrei andare con il vostro disegno quest'ultimo. Creare una classe chiamata SourceCodeParser, hanno il take costruttore nel nome del file, lo sviluppatore, ecc, e lo hanno ha un metodo di analisi. In questo modo l'oggetto è responsabile per l'analisi di sé.

In genere preferisco passare parametri al costruttore se non sono troppo numerosi. Codice completo raccomanda un massimo di 7 parametri. Se si trova il numero di parametri del costruttore ad essere ingombrante si può sempre creare setter fuori della classe SourceCodeParser succitati.

Se vuoi un modo per istituire un comportamento diverso di analisi mi consiglia di utilizzare un delegato parser all'interno di SourceCodeParser e che hanno da passare come sia un parametro del costruttore o di un setter.

Answer 3

Se si dispone di una classe che è unico scopo è quello di associare insieme vari pezzi di informazioni, quindi non vedo alcuna ragione per cui quella classe non deve essere utilizzato direttamente come parametro. Il motivo è che la classe è stato codificato per fare esattamente questo, quindi perché sarebbe non lasciar fare il suo lavoro? Così ho sicuramente preferisco il primo.

Ora, questo è supponendo che il Parser ha bisogno in realtà le informazioni come è semanticamente presentato in SourceCodeBean. Se tutto il Parser in realtà ha bisogno è un nome di file, allora dovrebbe solo prendere il nome del file, e preferirei il secondo metodo.

Credo che l'unica cosa che mi potrebbe preoccupare qui è SourceCodeBean diventando una sorta di "lavandino della cucina" di informazioni. Per esempio, i campi di nome file e formato hanno perfettamente senso qui. Ma non si ha realmente bisogno lo sviluppatore e le linee? Potrebbe essere quelli invece in una sorta di classe di metadati-informazioni associate?