Dove devo mettere i binding per l'iniezione di dipendenza?

Question

Dove devo mettere i binding per l'iniezione di dipendenza?

#1 da (4 voti)
#2 da (0 voti)
#3 da (-1 voti)

3

Sono nuovo all'iniezione di dipendenza e anche se mi è davvero piaciuto fino ad ora, non sono sicuro di dove dovrebbero andare i binding. Sto usando Guice in Java, quindi alcune delle cose che dico potrebbero essere specifiche solo per Guice. Come vedo, ci sono due opzioni:

Accompagna la / e classe / e di cui è necessario. Quindi, scrivi solo install(OtherClassModule.class) in qualunque altro modulo desideri essere in grado di usare detta classe. A mio avviso, il vantaggio è che le classi che vogliono usarlo (o gestire le classi che vogliono usarlo) non hanno bisogno di conoscere i dettagli dell'implementazione. Il problema che vedo è che cosa succede se due classi vogliono utilizzare due diverse versioni della stessa classe? C'è molta personalizzazione possibile a causa di DI e questo sembra limitare molto.

Implementato nel modulo della / e classe / e di cui è necessario. È il capovolgimento di ciò che ho detto sopra. Ora hai la personalizzazione, ma non l'incapsulamento.

C'è una terza opzione? Sto fraintendendo qualcosa di ovvio? Qual è la migliore pratica?

dependency-injection java google-guice

posta sinθ 06.05.2014 - 03:02

fonte

3 risposte

Leggi altre domande sui tag dependency-injection java google-guice

Costruire un DBAL da zero Cos'è un modo scalabile e pratico per cercare l'esistenza di un gruppo di stringhe in un file enorme

score 4 · Answer 1

Mark Seemann ha scritto ampiamente su questo argomento. Ecco un riassunto dei suoi punti.

Per il massimo riutilizzo, struttura il codice come una o più librerie e / o framework che non richiedono o menzionano nemmeno un particolare contenitore IoC e applicazione il cui unico compito è creare istanze concrete e introdurle reciprocamente (aka Root di composizione ). Una Root di composizione può incapsulare un contenitore IoC, oppure può semplicemente usare new -espressioni. I root di composizione non sono pensati per essere riusabili .
Dovrebbe essere semplice usare una libreria o un framework senza installare anche un contenitore IoC.
Utilizza iniezione costruttore per rendere librerie Dependency-Injection-friendly , anche se per praticità è possibile fornire alcuni metodi di creazione che dipendono da hard-code comuni. Questi metodi di creazione dovrebbero usare new -expressions, non un framework IoC.
Usa fabbriche astratte per rendere framework Dipendenza-Iniezione amichevole . Ad esempio, un framework web potrebbe necessitare di un modo per creare gestori di richieste. Facendo affidamento su un'interfaccia per tale operazione, i framework consentono alle applicazioni di personalizzare la creazione di gestori senza richiedere l'utilizzo di un particolare contenitore.

Quindi, per rispondere direttamente alla tua domanda: non definire nessun legame Guice per la tua biblioteca. Non dovresti far dipendere i tuoi clienti da un particolare framework. Se si desidera fornire un modo per creare oggetti con il set "normale" di dipendenze compilate, utilizzare new -expressions incapsulate all'interno di metodi o builder di creazione.

score 0 · Answer 2

Prima di tutto, presumo che questo codice sia una specie di API, altrimenti avresti saputo se esistessero due classi che volessero utilizzare diverse implementazioni.

Quindi, se vuoi un'API più dettagliata, scegli la prima alternativa. Se vuoi consentire a un programmatore di selezionare l'implementazione, vai alla seconda alternativa. Infine, se vuoi entrambi, consulta la domanda "Gambe del robot" nelle Domande frequenti su Guice .

score -1 · Answer 3

C'è invece una terza soluzione che sto usando.

Chiedi al modulo di accompagnare la (e) classe (e) per cui è necessario, ma hai più versioni differenti (usando l'ereditarietà in Guice) con diverse configurazioni. Quindi solo install(...) qualunque sia la versione che voglio. Il vantaggio è che è ancora incapsulato, ma è anche personalizzabile.