Cos'è esattamente l'iniezione di campo e come evitarla?

Ho letto in alcuni post su Spring MVC e Portlet che l' iniezione di campo non è consigliata. A quanto ho capito, l' iniezione sul campo è quando inietti un fagiolo con @Autowiredquesto:

@Component
public class MyComponent {
    @Autowired
    private Cart cart;
}

Durante la mia ricerca ho letto anche sull'iniezione del costruttore :

@Component
public class MyComponent {
    private final Cart cart;

    @Autowired
    public MyComponent(Cart cart){
       this.cart = cart;
    }
}

Quali sono i vantaggi e gli svantaggi di entrambi questi tipi di iniezioni?

EDIT 1: Poiché questa domanda è contrassegnata come duplicata di questa domanda, l' ho controllata. Perché non ci sono esempi di codice né nella domanda né nelle risposte, non è chiaro per me se ho ragione con la mia ipotesi su quale tipo di iniezione sto usando.

Tipi di iniezione

Ci sono tre opzioni su come le dipendenze possono essere iniettate in un bean:

1. Tramite un costruttore
2. Tramite setter o altri metodi
3. Attraverso la riflessione, direttamente nei campi

Stai usando l'opzione 3. Questo è ciò che accade quando usi @Autowireddirettamente sul tuo campo.

Linee guida per l'iniezione

Una linea guida generale, raccomandata da Spring (vedere le sezioni su DI basata su costruttore o DI basata su Setter ) è la seguente:

• Per le dipendenze obbligatorie o quando si punta all'immutabilità, utilizzare l'iniezione del costruttore
• Per dipendenze facoltative o modificabili, utilizzare l'iniezione di setter
• Evita l'iniezione sul campo nella maggior parte dei casi

Inconvenienti dell'iniezione di campo

I motivi per cui l'iniezione sul campo è disapprovata sono i seguenti:

• Non puoi creare oggetti immutabili, come puoi fare con l'iniezione nel costruttore
• Le tue classi hanno un accoppiamento stretto con il tuo contenitore DI e non possono essere utilizzate al di fuori di esso
• Le tue classi non possono essere istanziate (ad esempio negli unit test) senza riflessione. Hai bisogno del contenitore DI per istanziarli, il che rende i tuoi test più simili ai test di integrazione
• Le tue reali dipendenze sono nascoste dall'esterno e non si riflettono nella tua interfaccia (costruttori o metodi)
• È davvero facile avere dieci dipendenze. Se stavi usando l'iniezione del costruttore, avresti un costruttore con dieci argomenti, che segnalerebbero che qualcosa è sospetto. Ma puoi aggiungere campi iniettati usando l'inserimento di campi a tempo indeterminato. Avere troppe dipendenze è una bandiera rossa che la classe di solito fa più di una cosa e che potrebbe violare il Principio di responsabilità unica.

Conclusione

A seconda delle tue esigenze, dovresti usare principalmente l'iniezione del costruttore o una combinazione di iniezione del costruttore e setter. L'iniezione sul campo presenta molti inconvenienti e dovrebbe essere evitata. L'unico vantaggio dell'iniezione sul campo è che è più conveniente scrivere, il che non supera tutti i contro.

Ulteriore lettura

Ho scritto un articolo sul blog sul motivo per cui l'iniezione di campo di solito non è consigliata: Iniezione di dipendenza dal campo considerata dannosa .

Questa è una delle discussioni senza fine nello sviluppo del software, ma i principali influencer del settore stanno diventando più supponenti sull'argomento e hanno iniziato a suggerire l'iniezione del costruttore come l'opzione migliore.

Iniezione nel costruttore

Professionisti:

• Migliore testabilità . Non è necessaria alcuna libreria beffarda o un contesto Spring nei test unitari. È possibile creare un oggetto che si desidera testare con la nuova parola chiave. Tali test sono sempre più veloci perché non si basano sul meccanismo di riflessione. ( Questa domanda è stata posta 30 minuti dopo. Se l'autore avesse usato l'iniezione del costruttore non sarebbe apparsa).
• Immutabilità . Una volta impostate le dipendenze, non è possibile modificarle.
• Codice più sicuro . Dopo l'esecuzione di un costruttore il tuo oggetto è pronto per l'uso poiché puoi convalidare tutto ciò che è stato passato come parametro. L'oggetto può essere pronto o meno, non esiste uno stato intermedio. Con l'iniezione di campo si introduce una fase intermedia quando l'oggetto è fragile.
• Espressione più pulita delle dipendenze obbligatorie . L'iniezione sul campo è ambigua in questa materia.
• Fa riflettere gli sviluppatori sul design . dit ha scritto di un costruttore con 8 parametri, che in realtà è il segno di un cattivo design e dell'anti-pattern dell'oggetto Dio . Non importa se una classe ha 8 dipendenze nel suo costruttore o nei campi, è sempre sbagliato. Le persone sono più riluttanti ad aggiungere più dipendenze a un costruttore rispetto ai campi. Funziona come un segnale per il tuo cervello che dovresti fermarti per un po 'e pensare alla struttura del tuo codice.

Contro:

• Più codice (ma gli IDE moderni alleviano il dolore).

Fondamentalmente, l'iniezione di campo è l'opposto.

Questione di gusti. È una tua decisione.

Ma posso spiegare perché non uso mai l' iniezione del costruttore .

1. Non voglio implementare un costruttore per tutti i miei @Service, @Repositorye @Controllerfagioli. Voglio dire, ci sono circa 40-50 fagioli o più. Ogni volta che aggiungo un nuovo campo dovrei estendere il costruttore. No. Non lo voglio e non devo.

2. Cosa succede se il tuo Bean (servizio o controller) richiede l'iniezione di molti altri fagioli? Un costruttore con 4+ parametri è molto brutto.

3. Se sto usando CDI, il costruttore non mi riguarda.

EDIT # 1 : Vojtech Ruzicka ha detto:

class ha troppe dipendenze e probabilmente viola il principio di responsabilità unica e dovrebbe essere riformattato

Sì. Teoria e realtà. Ecco un esempio: DashboardControllermappato a percorso singolo *:8080/dashboard.

My DashboardControllerraccoglie molte informazioni da altri servizi per visualizzarle in una dashboard / pagina di panoramica del sistema. Ho bisogno di questo controller singolo. Quindi devo proteggere solo questo percorso (autenticazione di base o filtro del ruolo utente).

EDIT # 2 : poiché tutti sono concentrati sugli 8 parametri nel costruttore ... Questo era un esempio del mondo reale: un codice legacy dei clienti. L'ho cambiato. La stessa argomentazione si applica a me per 4+ parametri.

Si tratta di iniezione di codice, non di costruzione di istanze.

Un altro commento: Vojtech Ruzicka ha affermato che Spring inietta i fagioli in questi tre modi (la risposta con il maggior numero di punti):

1. Tramite un costruttore
2. Tramite setter o altri metodi
3. Attraverso la riflessione, direttamente nei campi

Questa risposta è SBAGLIATA, perché PER OGNI TIPO DI INIEZIONE LA MOLLA UTILIZZA LA RIFLESSIONE! Usa IDE, imposta il punto di interruzione sul setter / costruttore e controlla.

Questa può essere una questione di gusti ma può anche essere una questione di CASO. @dieter ha fornito un ottimo caso in cui l'iniezione sul campo è migliore. Se stai utilizzando l'iniezione sul campo nei test di integrazione che stanno configurando il contesto Spring, anche l'argomento con testabilità della classe non è valido, a meno che tu non voglia scrivere successivamente sui test nei tuoi test di integrazione;)