2010-11-03 16 views
6

Ho una domanda riguardante il modello di iniezione di dipendenza. La mia domanda è ... Se vado per l'iniezione del costruttore, iniettando le dipendenze per la mia classe, quello che ottengo è un costruttore "grande" con molti parametri. Cosa succede se vale a dire. Non uso alcuni dei parametri in alcuni metodi? Ie. Ho un servizio che espone molti metodi. E un costruttore con 10 parametri (tutte le dipendenze). Ma non tutti i metodi usano tutte le dipendenze. Alcuni metodi useranno solo una dipendenza, un'altra utilizzerà 3 dipendenze. Ma il contenitore DI li risolverà tutti anche se non utilizzati.Domanda di immissione in dipendenza

Per me questa è una penalità di prestazioni dell'utilizzo del contenitore DI. È vero?

risposta

0

È inoltre possibile nascondere alcune dipendenze non ancora necessarie dietro i provider pigri. Per esempio:

public DataSourceProvider implements Provider<DataSource> { 

    public DataSource get() { 
     return lazyGetDataSource(); 
    } 

} 

La Provider interface fa parte del pacchetto javax.inject.

0

In realtà non è possibile sapere quali metodi vengono utilizzati in fase di esecuzione quando si crea il contenitore DI. Dovresti affrontare questa penalità di prestazioni o se sai che ci sono molti casi in cui vengono utilizzate solo poche dipendenze, puoi dividere il tuo contenitore in diversi piccoli contenitori che hanno meno dipendenze che vengono iniettate.

7

Sembra che la tua classe stia facendo molto, che non sia conforme alla S in SOLID (Principio di responsabilità singola), forse potresti dividere la classe in più classi più piccole con meno dipendenze. Il fatto che non tutte le dipendenze siano usate da tutti i metodi suggerisce questo.

1

Normalmente la penalità delle prestazioni di iniettare molte dipendenze è bassa, ma dipende dal framework scelto. Alcuni compileranno metodi per questo al volo. Dovrai testarlo. Molte dipendenze indicano che la tua classe sta facendo troppo (come ha detto Ruben), quindi potresti voler dare un'occhiata a questo. Se la creazione di un'istanza di una dipendenza che non si utilizza spesso causa problemi di prestazioni, è possibile che si desideri introdurre una factory come dipendenza. Ho scoperto che l'uso delle fabbriche può risolvere molti problemi riguardanti l'uso di strutture di iniezione delle dipendenze.

0

Come dice Rube probabilmente si dovrebbe rivedere il design della classe per attenersi ai principi SOLID.

Ad ogni modo se non è veramente necessario sono abituato ad andare per la dipendenza da setter di proprietà del costruttore. Significa che puoi creare una proprietà per ogni dipendenza di cui hai bisogno. Ciò aiuta anche a testare la classe perché è possibile iniettare solo la dipendenza di cui si ha bisogno nel contesto del test che si sta eseguendo invece di eliminare tutta la dipendenza anche se non è necessario.

+1

Lo stato mutevole deve essere evitato costi. –

+0

Sono d'accordo. Sulla mia risposta sono d'accordo con Rube che ha detto che probabilmente avrebbe dovuto rivedere il design della sua classe. Il mio secondo commento è stato solo pratico :-) –