Wie funktioniert Dependency Injection in Spring, und warum bevorzugst du Constructor Injection?

Der Container baut Beans und liefert ihnen ihre Mitspieler, Klassen deklarieren also, was sie brauchen, statt es selbst zu konstruieren. Constructor Injection ist zu bevorzugen, weil die Abhängigkeiten verpflichtend und sichtbar sind, die Felder final sein können und das Objekt damit unveränderlich und vollständig initialisiert ist, die Klasse mit einem schlichten new und ohne Reflection testbar bleibt, und eine zirkuläre Abhängigkeit beim Start laut scheitert, statt sich hinter fauler Field Injection zu verstecken.

Der Container besitzt die Objekterzeugung, meine Klasse fragt also im Konstruktor nach dem, was sie braucht, und Spring löst das auf und injiziert es. Ich nutze Constructor Injection, weil sie den Vertrag sichtbar macht: nimmt eine Klasse fünf Mitspieler entgegen, steht das jetzt in der Signatur, statt über fünf annotierte Felder versteckt zu sein, und meistens sagt mir das, dass die Klasse zu viel macht. Die Felder können final sein, das Objekt ist also vollständig konstruiert und sicher über Threads hinweg zu veröffentlichen, und ich kann es im Test mit schlichten Konstruktorargumenten und ganz ohne Spring-Kontext instanziieren, was Unit-Tests schnell hält. Zirkuläre Abhängigkeiten tauchen außerdem beim Start als Fehler auf, statt übertüncht zu werden. Zu Scopes: Beans sind per Default Singletons, ich halte sie also zustandslos; ein veränderliches Feld auf einem Singleton-Service ist eine Race Condition, die auf nebenläufige Requests wartet. Brauche ich Zustand pro Request, übergebe ich ihn als Methodenparameter, statt zu einer request-scoped Bean zu greifen. Field Injection meide ich aktiv, denn sie versteckt Abhängigkeiten und braucht im Test Reflection zum Aufsetzen.