Dipendenza da iniezione di dipendenza?

StackOverflow https://stackoverflow.com/questions/42706

  •  09-06-2019
  •  | 
  •  

Domanda

C'è un lato negativo?Adesso mi sento quasi dipendente da questo.Ogni volta che un progetto supera una certa dimensione, si avverte quasi una reazione allergica ai modelli standard e lo si ricollega immediatamente con un framework di Dependency Injection.

Il problema più grande che ho riscontrato è che può creare confusione per gli altri sviluppatori che lo stanno appena imparando.

Inoltre, mi sentirei molto meglio se fosse parte della lingua che sto usando.Tuttavia, almeno per Java, ci sono un paio di librerie molto leggere che sono abbastanza buone.

Pensieri?Brutte esperienze?O semplicemente smetti di preoccupartene?

[MODIFICA] Rif:Descrizione dell'inserimento delle dipendenze stesso

Scusa se sono stato vago. Martin Fowler probabilmente lo descrive MOLTO meglio di quanto avrei mai potuto...non c'è bisogno di sprecare lo sforzo.

Per coincidenza, ciò conferma un punto a riguardo, ovvero che non è ancora ampiamente praticato e potrebbe tendere a rappresentare una barriera quando si lavora con i team se tutti non sono al passo con i tempi.

È stato utile?

Soluzione

Ho provato a descrivere alcuni dei possibili aspetti negativi in ​​un post sul blog qui: http://kevin-berridge.blogspot.com/2008/06/ioc-and-di-complexity.html

Altri suggerimenti

Il problema che ho con DI è lo stesso problema che ho con COM e con qualsiasi codice che assomigli a:

i = GetServiceOrInterfaceOrObject(...)

Il problema è che un sistema del genere non può essere compreso dal codice.Deve esserci documentazione da qualche altra parte [altro] che definisce quale servizio/interfaccia/oggetto può essere richiesto dal servizio/interfaccia/oggetto X.Questa documentazione non deve solo essere mantenuta, ma essere disponibile con la stessa facilità della fonte.

A meno che il documento non sia scritto molto bene, spesso non è ancora facile vedere le relazioni tra gli oggetti.A volte le relazioni sono temporali, il che le rende ancora più difficili da scoprire.

Mi piace il principio KISS e credo fermamente nell'utilizzo dello strumento giusto per il lavoro.Se il vantaggio del DI, per un dato progetto, supera la necessità di scrivere codice comprensibile, allora usalo.

Inoltre, mi sentirei molto meglio se facesse parte della lingua che stavo usando.

Per tua informazione esiste un'iniezione di dipendenza molto semplice e funzionale come parte di JDK 6.Se hai bisogno di un'iniezione di dipendenza leggera e diretta, usala.

Utilizzando ServiceLoader class puoi richiedere un servizio (o più implementazioni del servizio) in base a una classe:

 package dependecyinjection;  
 import java.util.ServiceLoader;  

 public abstract class FooService {  

     public static FooService getService() {  
         ServiceLoader<FooService> loader = ServiceLoader.load(FooService.class);  

         for (FooService service : loader) {  
             return provider;  
         }  

         throw new Exception ("No service");  
     }  

     public abstract int fooOperation();  

 }  

 package dependecyinjection;  
 public class FooImpl extends FooService {  
     @Override  
     public int fooOperation() {  
         return 2;  
     }  
 }

In che modo ServiceLoader definisce le implementazioni del servizio restituite?

Nella cartella del tuo progetto crea una cartella denominata META-INF/servizi e creare un file denominato dependencyinjection.FooService.Questo file contiene una riga che punta all'implementazione del servizio.In quel caso:dependecyinjection.FooImpl

Questo non è ancora ampiamente noto.

Sono un grande sostenitore di IO, tuttavia ho visto alcuni progetti con enormi file di configurazione XML che nessuno capisce.Quindi attenzione alla programmazione in xml.

A mio parere, i principali svantaggi sono la curva di apprendimento (come fai notare) e il potenziale per l'astrazione aggiunta di rendere più difficile il debug (che in realtà fa anche parte della curva di apprendimento).

Per me, DI mi sembra più appropriato per sistemi più grandi e complessi: per piccole app una tantum, potrebbe comportare un'architettura eccessiva dell'app, in pratica, poiché l'architettura richiede più tempo di sviluppo per aderire rispetto a quanto necessario potrà mai compensare con il valore che offre.

Smettila di preoccupartene.È mia opinione che col tempo le tecniche IoC diventeranno una seconda natura per la maggior parte degli sviluppatori.Sto cercando di insegnarlo agli sviluppatori qui al lavoro e trovo difficile trasmettere il messaggio perché sembra così innaturale rispetto al modo in cui abbiamo sempre fatto le cose.che guarda caso era stato nel modo sbagliato.Inoltre, trovo che gli sviluppatori nuovi a IoC e nuovi a un progetto abbiano ancora più difficoltà.Sono abituati a utilizzare l'IDE per seguire la scia delle dipendenze per comprendere come l'intera cosa "sta insieme".Tali informazioni sono spesso scritte in un XML arcano.

Potresti aggiungere uno o due link per spiegare cos'è effettivamente la Dependency Injection, per quelli di noi che giocano a casa?IL articolo di Wikipedia è divertente, ma non molto illuminante.

L'unico lato negativo a cui riesco a pensare è un piccolo calo delle prestazioni dovuto alle continue chiamate virtuali :)

@Blorgbeard: http://www.martinfowler.com/articles/injection.html è probabilmente uno dei migliori articoli sull'argomento

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top