Antwort.

Dependency Inversion Principle (DIP) ist ein architektonisches Prinzip, das besagt:

• Module höherer Ebene sollten nicht von Modulen niedrigerer Ebene abhängen. Beide Typen sollten von Abstraktionen (Schnittstellen) abhängen.
• Abstraktionen sollten nicht von Details abhängen, Details sollten von Abstraktionen abhängen.

Das bedeutet, dass die Geschäftslogik (z.B. ein Service zur Bearbeitung von Bestellungen) nicht wissen und nicht direkt eine spezifische Implementierung der Infrastruktur (z.B. eine Klasse, die das Versenden von E-Mails implementiert) verwenden sollte, sondern über eine Abstraktion (Schnittstelle) arbeiten sollte, die durch einen DI-Container oder manuell bereitgestellt wird.

Beispielcode in C#:

public interface IEmailSender {
    void Send(string to, string message);
}

public class SmtpEmailSender : IEmailSender {
    public void Send(string to, string message) {
        // Implementierung des E-Mail-Versands
    }
}

public class OrderService {
    private readonly IEmailSender _emailSender;

    public OrderService(IEmailSender emailSender) {
        _emailSender = emailSender;
    }
    public void PlaceOrder(string customer) {
        // Geschäftslogik
        _emailSender.Send(customer, "Ihre Bestellung wurde aufgegeben!");
    }
}

Hauptmerkmale:

• Ermöglicht es, Implementierungsdetails leicht zu ersetzen (z.B. das Einfügen von Mocks in Tests).
• Erhöht die Testbarkeit und Erweiterbarkeit der Architektur.
• Gewährleistet eine lose Kopplung der Module.

Knifflige Fragen.

Ist DIP einfach die Abhängigkeitseinfügung über den Konstruktor?

Nein. DIP handelt von der Trennung von Abstraktionen und Implementierungen. Die Abhängigkeitseinfügung (Dependency Injection, DI) ist lediglich ein Werkzeug, mit dem DIP umgesetzt wird. DIP kann auch ohne DI-Container manuell durch die Trennung von Abstraktionen und Details realisiert werden.

Wenn Sie eine Implementierung der Schnittstelle haben, ist DIP dann zwingend erforderlich?

Ja, das Prinzip ist trotzdem anwendbar, wenn eine Erweiterung möglich ist. Die Einführung von Abstraktionen bereitet das System auf Änderungen der Anforderungen vor, ohne dass der Code der höheren Ebene modifiziert werden muss. Selbst mit einer Implementierung der Schnittstelle erleichtert die lose Kopplung das Testen und die Weiterentwicklung des Systems.

Kann DIP verletzt werden, indem Logik in Fabriken oder Service-Standorten verwendet wird?

Ja. Wenn die Fabrik oder der Service-Standort von den Implementierungsdetails weiß und diese dynamisch bindet, ohne eine Schnittstelle auf der Client-Seite zu verwenden, wird DIP verletzt, trotz des externen Vorhandenseins von Abstraktionen.