Welches der SOLID-Prinzipien fällt Ihnen in der Praxis am schwersten?

Prinzip der Barbara Liskov (LSP).

Die Schwierigkeit besteht darin, dass Verstöße gegen den LSP nicht immer auf den ersten Blick offensichtlich sind und nur bei Verwendung von Unterklassen in einem Kontext erkannt werden können, in dem das Verhalten der Basisklasse erwartet wird. Dies erfordert ein tiefes Verständnis des beabsichtigten Verhaltens der Basisklasse und gründliche Tests.

Beispiel für einen Verstoß:

class Rectangle {
    var width: Double = 0
    var height: Double = 0

    func setWidth(_ width: Double) { self.width = width }
    func setHeight(_ height: Double) { self.height = height }

    func area() -> Double { width * height }
}

class Square: Rectangle {
    override func setWidth(_ width: Double) {
        super.setWidth(width)
        super.setHeight(width) // Verletzung des LSP: Änderung der Breite beeinflusst die Höhe
    }

    override func setHeight(_ height: Double) {
        super.setHeight(height)
        super.setWidth(height) // Verletzung des LSP: Änderung der Höhe beeinflusst die Breite
    }
}

Wenn Square dort verwendet wird, wo Rectangle erwartet wird, führt das Verhalten von Square beim Ändern nur einer Seite (Breite oder Höhe) zu unvorhersehbaren Ergebnissen, da die Basisklasse Rectangle dieses Verhalten nicht hat.

Um Verstöße gegen den LSP zu vermeiden, ist es oft notwendig, Klassenhierarchien neu zu überdenken, Komposition anstelle von Vererbung zu verwenden oder abstraktere Schnittstellen/Protokolle einzuführen. Dies kann die Komplexität im Design in den Anfangsphasen erhöhen.

Vergleichstabelle:

SOLID-Prinzip	Kurze Beschreibung	Hauptschwierigkeit bei der Anwendung des LSP
S (SRP)	Eine Klasse - ein Grund für Änderungen	Die "einzige Ursache" finden
O (OCP)	Offen für Erweiterungen, geschlossen für Änderungen	Richtige Nutzung von Abstraktionen
L (LSP)	Unterklassen sollten austauschbar durch Basisklassen sein	Nicht offensichtliche Verstöße, erfordern Verständnis des Vertrags der Basisklasse
I (ISP)	Kunden sollten nicht von nicht genutzten Methoden abhängen	Schnittstellen aufteilen
D (DIP)	Abhängigkeit von Abstraktionen, nicht von konkreten Implementierungen	Dependency Injection