Comprendo i vantaggi dell'iniezione di dipendenza stessa. Prendiamo ad esempio la primavera. Capisco anche i vantaggi di altre funzionalità di Spring come AOP, helper di diverso tipo, ecc. Mi chiedo solo quali sono i vantaggi della configurazione XML come:
<bean id="Mary" class="foo.bar.Female">
<property name="age" value="23"/>
</bean>
<bean id="John" class="foo.bar.Male">
<property name="girlfriend" ref="Mary"/>
</bean>rispetto al semplice vecchio codice java come:
Female mary = new Female();
mary.setAge(23);
Male john = new Male();
john.setGirlfriend(mary);che è più facile da eseguire il debug, il tempo di compilazione controllato e può essere compreso da chiunque conosca solo java. Allora qual è lo scopo principale di un framework di inserimento delle dipendenze? (o un pezzo di codice che mostra i suoi vantaggi.)
AGGIORNAMENTO:
In caso di
IService myService;// ...
public void doSomething() {
myService.fetchData();
}Come può il framework IoC indovinare quale implementazione di myService desidero venga iniettata se ce n'è più di una? Se è presente una sola implementazione di una determinata interfaccia e lascio che il contenitore IoC decida automaticamente di usarla, verrà interrotta dopo la visualizzazione di una seconda implementazione. E se c'è intenzionalmente solo una possibile implementazione di un'interfaccia, non è necessario iniettarla.
Sarebbe davvero interessante vedere un piccolo pezzo di configurazione per IoC che mostra i suoi vantaggi. Uso Spring da un po 'e non posso fornire un simile esempio. E posso mostrare singole righe che dimostrano i vantaggi di hibernate, dwr e altri framework che utilizzo.
AGGIORNAMENTO 2:
Mi rendo conto che la configurazione IoC può essere modificata senza ricompilare. È davvero una buona idea? Riesco a capire quando qualcuno vuole cambiare le credenziali del DB senza ricompilarlo: potrebbe non essere uno sviluppatore. Nella tua pratica, con che frequenza qualcun altro diverso dallo sviluppatore cambia la configurazione IoC? Penso che per gli sviluppatori non ci sia alcuno sforzo per ricompilare quella particolare classe invece di cambiare la configurazione. E per i non sviluppatori probabilmente vorrai semplificargli la vita e fornire un file di configurazione più semplice.
AGGIORNAMENTO 3:
Configurazione esterna della mappatura tra interfacce e loro implementazioni concrete
Cosa c'è di così buono nel renderlo extenal? Non rendi tutto il tuo codice esterno, mentre sicuramente puoi - basta inserirlo nel file ClassName.java.txt, leggere e compilare manualmente al volo - wow, hai evitato di ricompilare. Perché si dovrebbe evitare la compilazione ?!
Risparmi tempo di codifica perché fornisci le mappature in modo dichiarativo, non in un codice procedurale
Capisco che l'approccio a volte dichiarativo fa risparmiare tempo. Ad esempio, dichiaro solo una volta che una mappatura tra una proprietà del bean e una colonna DB e hibernate utilizza questa mappatura durante il caricamento, il salvataggio, la creazione di SQL basato su HSQL, ecc. È qui che funziona l'approccio dichiarativo. Nel caso di Spring (nel mio esempio), la dichiarazione aveva più righe e aveva la stessa espressività del codice corrispondente. Se c'è un esempio in cui tale dichiarazione è più breve del codice, mi piacerebbe vederlo.
Il principio di inversione del controllo consente un facile test delle unità perché è possibile sostituire le implementazioni reali con quelle false (come la sostituzione del database SQL con uno in memoria)
Capisco l'inversione dei vantaggi del controllo (preferisco chiamare il modello di progettazione discusso qui come Dependency Injection, perché IoC è più generale: ci sono molti tipi di controllo e ne stiamo invertendo solo uno: controllo dell'inizializzazione). Stavo chiedendo perché qualcuno abbia mai bisogno di qualcosa di diverso da un linguaggio di programmazione per questo. Posso sicuramente sostituire le implementazioni reali con quelle false usando il codice. E questo codice esprimerà la stessa cosa della configurazione: inizializzerà solo i campi con valori falsi.
mary = new FakeFemale();Capisco i vantaggi di DI. Non capisco quali vantaggi vengono aggiunti dalla configurazione XML esterna rispetto alla configurazione del codice che fa lo stesso. Non credo che la compilazione debba essere evitata: compilo tutti i giorni e sono ancora vivo. Penso che la configurazione di DI sia un cattivo esempio di approccio dichiarativo. La dichiarazione può essere utile se viene dichiarata una volta AND viene utilizzata molte volte in modi diversi, come hibernate cfg, dove la mappatura tra la proprietà del bean e la colonna DB viene utilizzata per il salvataggio, il caricamento, la creazione di query di ricerca, ecc. La configurazione di Spring DI può essere facilmente tradotta in configurare il codice, come all'inizio di questa domanda, non è vero? Ed è usato solo per l'inizializzazione dei bean, non è vero? Il che significa che un approccio dichiarativo non aggiunge nulla qui, vero?
Quando dichiaro la mappatura di ibernazione, fornisco solo alcune informazioni di ibernazione e funziona in base ad essa - non gli dico cosa fare. In caso di primavera, la mia dichiarazione dice alla primavera esattamente cosa fare, quindi perché dichiararla, perché non farlo e basta?
ULTIMO AGGIORNAMENTO:
Ragazzi, molte risposte mi dicono sull'iniezione di dipendenza, che SO È BENE. La domanda riguarda lo scopo della configurazione DI invece di inizializzare il codice: tendo a pensare che l'inizializzazione del codice sia più breve e più chiara. L'unica risposta che ho ottenuto finora alla mia domanda, è che evita la ricompilazione, quando la configurazione cambia. Immagino che dovrei pubblicare un'altra domanda, perché è un grande segreto per me, perché in questo caso la compilazione dovrebbe essere evitata.