Eine Klasse braucht selten nur sich selbst. Ein Rechnungsversand braucht einen Mailversand, der wiederum Zugangsdaten braucht. Die Frage ist, wer diese Teile zusammensteckt.
Die naheliegende Antwort wäre, dass jede Klasse sich ihre Abhängigkeiten selbst besorgt. Damit ist sie aber fest an eine bestimmte Umsetzung gebunden. Der Service Container dreht das um. Eine Klasse sagt, was sie braucht, und bekommt es geliefert. Das Prinzip dahinter heißt Dependency Injection.
Warum das praktisch zählt
Erstens Tests. Bekommt eine Klasse ihren Mailversand geliefert, kann im Test ein Platzhalter einspringen, der nichts verschickt, aber festhält, was verschickt worden wäre. Ohne diese Trennung müsste jeder Test echte Mails erzeugen oder ganz entfallen.
Zweitens Austauschbarkeit. Der Wechsel eines Zahlungs- oder Versanddienstleisters betrifft dann eine einzige Stelle statt jeder Klasse, die ihn benutzt.
Drittens Klarheit. Was eine Klasse braucht, steht sichtbar in ihrer Signatur, statt versteckt in ihrem Innenleben aufzutauchen.