Vedere la domanda nel titolo! Vorresti "iniettare" o piuttosto "nuovo" un comparatore? Ne avresti una nuova se l'ordine degli elementi è impostato nella specifica e probabilmente non cambierà?I Comparatori sono oggetti nuovi o iniettabili?
La domanda "devo iniettare questa dipendenza?" è davvero "dovrebbe l'oggetto di riferimento conoscere la natura di questa dipendenza?". Er, solo negato.
Se la tua classe è un FastestPonyFinder, e ha bisogno di ordinare un List<Pony> di velocità, quindi direi che dovrebbe conoscere il comparatore. Il comparatore deve confrontare per velocità, ordinando il più veloce in testa alla lista; nessun altro comparatore è adatto per il lavoro. L'oggetto dovrebbe creare il comparatore, proprio come ha creato lo List.
Se la tua classe è un BestPonyFinder, allora probabilmente dovrebbe essere iniettato il comparatore, perché la definizione di ciò che costituisce "il migliore" è separabile dalla definizione di come trovare il pony che lo soddisfa. Questo renderà il tuo codice più facile da testare e più facile da cambiare in futuro.
Grazie per la risposta! Seguendo questa linea di pensiero, avresti quindi 'nuovo' un TodaysPoniesFinder in FastestPonyFinder quando saprai che la tua applicazione funzionerà sempre su gare di pony in un giorno specifico? O sceglieresti diversamente, considerando che TodaysPoniesFinder è probabilmente qualcosa di più complesso di un comparatore? (Si prega di ignorare il fatto, che probabilmente non farebbe qualcosa come un 'TodaysPoniesFinder' considerando i problemi di testabilità delle date :)). Grazie! – user1405469
Se il lavoro di 'TodaysPoniesFinder' è di fare una lista di tutti i pony in competizione oggi, allora direi che il' FastestPonyFinder' non ha bisogno di sapere cosa sta facendo; importa solo che produce una lista di pony. Pertanto, dovrebbe essere iniettato. Probabilmente dovrebbe essere iniettato come parametro di qualche tipo come "PonyFinder", piuttosto che come tipo concreto. –
Per inciso, 'TodaysPoniesFinder' sarebbe perfettamente testabile - a condizione di iniettare il valore di" oggi "! Questa è una [mossa classica nel TDD mockista] (http://www.mockobjects.com/2007/04/test-smell-i-need-to-mock-object-i-cant.html); tipicamente scrivi un 'clock di classe molto semplice {public Date now() {return new Date(); }} 'e lo inserisco in qualsiasi oggetto che abbia bisogno di sapere l'ora. È quindi possibile iniettare una simulazione per testare. –
La cosa sui comparatori è che sono economici. Spesso non hanno campi, e se lo fanno, non ne hanno molti.
Sono così economici che non importa. Puoi costruirli in linea, o ottenerli da un campo finale statico, o ottenere un'iniezione singleton - a chi importa?
Da una prospettiva di testing unitario, in pratica stai dicendo che i Comparators sono economici, proprio come i metodi getter/setter, giusto? Quindi, non prendere in considerazione la scrittura di test per loro ... – user1405469
Depends. Proverei certamente i metodi che li usano. –
Inoltre, se non c'è stato, è sempre possibile "riutilizzare" quindi. In questo caso sono thread-safe e non entrano in uno stato da un uso precedente. Quindi alla fine dipende davvero da come hai implementato il comparatore: con stato o senza.
Per il test dell'unità è meglio disporre di una nuova istanza di Comparator, ma non importa se il proprio comparatore implementa semplicemente il metodo di confronto. Se si desidera iniettare alcuni dati come stato per il confronto e si possono utilizzare i metodi di prova Prima e Dopo, per assicurarsi di non utilizzare il contesto precedente.
Buona domanda! Le risposte rivelano una vasta gamma di idee su ciò che l'iniezione è fondamentalmente * per *. –