Wir haben Autowiring bereits SEIT Kapitel 8 genutzt (LoggerInterface, Repositories, EntityManagerInterface), ohne das dahinterliegende Prinzip explizit zu benennen. Zeit, das Fundament nachzuholen, auf dem GANZ Symfony aufbaut.

Das Problem, das Dependency Injection löst

Stellen Sie sich vor, eine Klasse würde ihre Abhängigkeiten SELBST erzeugen:

class BenachrichtigungsService
{
    public function sendeBenachrichtigung(string $nachricht): void
    {
        $logger = new \Monolog\Logger('app'); // fest verdrahtet!
        $logger->info($nachricht);
    }
}

Drei konkrete Probleme: Die Klasse ist FEST an EINE bestimmte Logger-Implementierung gebunden (schwer austauschbar). Sie lässt sich NUR schwer isoliert testen (Kapitel 42 braucht dafür einen austauschbaren Fake-Logger). Und ändert sich, WIE der Logger konfiguriert wird, müssen ALLE Stellen angepasst werden, die ihn selbst erzeugen.

Die Lösung: Abhängigkeiten von außen hereinreichen

use Psr\Log\LoggerInterface;

class BenachrichtigungsService
{
    public function __construct(
        private readonly LoggerInterface $logger,
    ) {
    }

    public function sendeBenachrichtigung(string $nachricht): void
    {
        $this->logger->info($nachricht);
    }
}

GENAU dieses Muster kennen wir bereits aus JEDEM Controller in dieser Schulung – die Klasse fordert NUR ein Interface an (LoggerInterface, nicht die konkrete Logger-Klasse), OHNE zu wissen, WOHER die tatsächliche Implementierung kommt. Das Bereitstellen dieser Implementierung übernimmt Symfonys Service Container.

Der Service Container: Symfonys zentrale Fabrik

Der Container ist ein GROSSES Verzeichnis: "Wird LoggerInterface angefragt, liefere DIESE konkrete Instanz." Für JEDES use-Statement eines Constructor-Parameters prüft Symfony automatisch, ob eine passende Service-Definition existiert – GENAU das ist Autowiring.

php bin/console debug:container

Listet ALLE registrierten Services – ein guter erster Anlaufpunkt bei der Fehlersuche, wenn Autowiring "nicht funktioniert" (meist: der gesuchte Service existiert schlicht nicht unter dem erwarteten Namen).

php bin/console debug:autowiring Logger

Zeigt speziell, WELCHE Interfaces/Klassen mit "Logger" im Namen per Autowiring verfügbar sind – nützlich, um den EXAKTEN Typ für einen Constructor-Parameter zu finden.

Services sind standardmäßig Singletons

PRO Request wird JEDER Service NUR EINMAL instanziiert – fordern zehn verschiedene Klassen LoggerInterface an, erhalten ALLE ZEHN dieselbe Instanz. Das spart Speicher UND garantiert konsistenten Zustand (z. B. ein einmal geöffneter Datenbank-Connection wird wiederverwendet, statt zehnmal neu aufgebaut zu werden).

Dependency Injection vs. das Service-Locator-Anti-Pattern

Warum dieses Prinzip so zentral für Symfony ist