La Dependency Injection vale la pena al di fuori di UnitTesting

Dato un costruttore che non dovrà mai e poi mai usare diverse implementazioni di diversi oggetti che inizializza, è ancora pratico usare DI? Dopotutto, potremmo ancora voler effettuare unit test.

La classe in questione inizializza alcune altre classi nel suo costruttore e le classi che utilizza sono piuttosto specifiche. Non utilizzerà mai un'altra implementazione. Siamo giustificati nell'evitare di provare a programmare su un'interfaccia?

Dipende da quanto sei sicuro che "mai, mai" sia corretto (durante il periodo in cui l'app verrà utilizzata).

In generale:

• Non modificare il progetto solo per testabilità. I test unitari sono lì per servirti, non viceversa.
• Non ripeterti. Fare un'interfaccia che avrà sempre un solo erede è inutile.
• Se una classe non è verificabile, probabilmente non è flessibile / estensibile nemmeno per casi d'uso reali. A volte va bene - è improbabile che tu abbia bisogno di quella flessibilità, ma semplicità / affidabilità / manutenibilità / prestazioni / qualunque cosa sia più importante.
• Se non lo sai, codifica l'interfaccia. I requisiti cambiano.

Siamo giustificati nell'evitare di provare a programmare su un'interfaccia?

Mentre il vantaggio della codifica rispetto a un'interfaccia è abbastanza evidente, dovresti chiederti cosa si ottiene esattamente non facendolo.

La domanda successiva è: fa parte della responsabilità della classe in questione scegliere le implementazioni o no? Questo può o non può essere il caso e dovresti agire di conseguenza.

In definitiva, c'è sempre il potenziale per qualche sciocco vincolo che esce dal nulla. Potresti voler eseguire lo stesso codice contemporaneamente, e la possibilità di iniettare l'implementazione potrebbe aiutare con la sincronizzazione. Oppure, dopo aver creato il profilo della tua app, potresti scoprire che desideri una strategia di allocazione diversa dalla semplice istanza. Oppure emergono preoccupazioni trasversali e non hai il supporto AOP a portata di mano. Chissà?

YAGNI suggerisce che quando si scrive il codice, è importante non aggiungere nulla di superfluo. Una delle cose che i programmatori tendono ad aggiungere al loro codice senza nemmeno esserne consapevoli, sono ipotesi superflue. Come "questo metodo potrebbe tornare utile" o "questo non cambierà mai". Entrambi aggiungono disordine al tuo design.

Dipende da vari parametri ma qui ci sono alcuni motivi per cui potresti voler usare DI:

• il test è piuttosto una buona ragione in sé credo
• le classi richieste dal tuo oggetto potrebbero essere utilizzate in altri luoghi - se le inietti ti consente di mettere in comune le risorse (ad esempio se le classi in questione sono thread o connessioni al database - non vuoi che ciascuna delle tue classi crei nuove connessioni)
• se l'inizializzazione di quegli altri oggetti non riesce, il codice più in alto nello stack sarà probabilmente migliore nel gestire i problemi rispetto alla tua classe, che probabilmente inoltrerà semplicemente gli errori

In conclusione: probabilmente puoi vivere senza DI in quel caso, ma ci sono possibilità che l'uso di DI finisca in un codice più pulito.

Quando progetti un programma o una funzione, parte del processo di pensiero dovrebbe essere il modo in cui lo testerai. L'iniezione di dipendenza è uno degli strumenti di test e dovrebbe essere considerata come parte del mix.

I vantaggi aggiuntivi di Dependency Injection e l'uso delle interfacce anziché delle classi sono utili anche quando un'applicazione viene estesa, ma possono anche essere adattati al codice sorgente in un secondo momento in modo abbastanza semplice e sicuro usando la ricerca e la sostituzione. - anche su progetti molto grandi.

 > Dependency Injection worth it **outside** of UnitTesting?
 > Are we justified in avoiding trying to program to an interface?

Molte risposte a questa domanda possono essere discusse come "potresti averne bisogno perché .." come YAGNI se non vuoi fare unittest.

Se stai chiedendo quali motivi oltre agli unittest richiedono di programmare su un'interfaccia

Sì , l'iniezione di dipendenza ne vale la pena al di fuori di UnitTesting se è necessaria l' inversione del controllo . Ad esempio, se l'implementazione di un modulo necessita di un altro modulo non accessibile nel suo livello.

Esempio: se hai i moduli gui=> businesslayer=> driver=> common.

In questo scenario è businesslayerpossibile utilizzare driverma drivernon è possibile utilizzare businesslayer.

Se è drivernecessaria una funzionalità di livello superiore, è possibile implementare questa funzionalità in businesslayercui implementa un'interfaccia a commonlivello. driverdeve solo conoscere l'interfaccia in commonlayer.

Sì, in primo luogo, dimentica i test unitari come motivo per progettare il tuo codice attorno agli strumenti di test unitari, non è mai una buona idea piegare il design del tuo codice per adattarlo a un vincolo artificiale. Se i tuoi strumenti ti costringono a farlo, ottieni strumenti migliori (ad esempio Microsoft Fakes / Moles che ti consentono molte più opzioni per la creazione di oggetti finti).

Ad esempio, divideresti le tue classi in metodi solo pubblici solo perché gli strumenti di test non funzionano con metodi privati? (So ​​che la saggezza prevalente è far finta di non aver bisogno di testare metodi privati, ma ritengo che questa sia una reazione alla difficoltà nel farlo con gli strumenti attuali, non una reazione reale alla non necessità di testare i privati).

Tutto sommato, dipende da che tipo di TDDer sei: il "mockist" come li descrive Fowler , deve cambiare il codice per adattarlo agli strumenti che usano, mentre i tester "classici" creano test che sono più integrati nella natura (ad esempio testare la classe come unità, non ogni metodo), quindi vi è meno necessità di interfacce, specialmente se si utilizzano strumenti che possono deridere classi concrete.

L'iniezione delle dipendenze rende anche più chiaro che il tuo oggetto HA dipendenze.

Quando qualcun altro usa il tuo oggetto in modo ingenuo (senza guardare il costruttore), scopriranno che dovranno impostare servizi, connessioni, ecc. Non erano ovvi perché non dovevano passarli al costruttore . Passare le dipendenze rende più chiaro ciò che è necessario.

Stai anche nascondendo il fatto che la tua classe potrebbe violare SRP. Se si passa in molte dipendenze (più di 3), la classe potrebbe fare troppo e dovrebbe essere rifattorizzata. Ma se li stai creando nel costruttore, questo odore di codice sarà nascosto.

Sono d'accordo con entrambi i campi qui e la questione è ancora aperta al dibattito secondo me. YAGNI mi chiede di non affrontare il cambiamento del mio codice per adattarlo alla supposizione. I test unitari non sono un problema qui perché credo fermamente che la dipendenza non cambierà mai e poi mai. Ma se fossi stato il test unitario come previsto per cominciare, non avrei mai raggiunto questo punto comunque. Come avrei eventualmente ridotto in DI.

Consentitemi di offrire un'altra alternativa specifica per il mio scenario

Con un modello di fabbrica posso localizzare le dipendenze in un unico posto. Durante i test posso cambiare l'implementazione in base al contesto, e questo è abbastanza buono. Questo non va contro YAGNI a causa dei benefici dell'astrazione di diverse costruzioni di classe.