Lequel des principes SOLID vous est le plus difficile à appliquer en pratique?

Principe de substitution de Barbara Liskov (LSP).

La difficulté réside dans le fait que la violation du LSP n'est pas toujours évidente au premier abord et peut ne se révéler qu'en utilisant des sous-classes dans un contexte où le comportement de la classe de base est attendu. Cela nécessite une compréhension approfondie du comportement prévu de la classe de base et des tests approfondis.

Exemple de violation:

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) // Violation du LSP : changer la largeur influence la hauteur
    }

    override func setHeight(_ height: Double) {
        super.setHeight(height)
        super.setWidth(height) // Violation du LSP : changer la hauteur influence la largeur
    }
}

Si l'on utilise Square là où l'on attend Rectangle, le comportement de Square en changeant un seul côté (largeur ou hauteur) conduira à des résultats imprévisibles, car la classe de base Rectangle n'a pas ce comportement.

Pour éviter les violations du LSP, il faut souvent repenser les hiérarchies de classes, utiliser la composition plutôt que l'héritage ou introduire des interfaces/protocoles plus abstraits. Cela peut ajouter de la complexité dans la conception aux premières étapes.

Tableau comparatif:

Principe SOLID	Description courte	Difficulté principale d'application du LSP
S (SRP)	Une classe - une raison de changer	Trouver la "seule raison"
O (OCP)	Ouvert à l'extension, fermé à la modification	Bonne utilisation des abstractions
L (LSP)	Les sous-classes doivent être remplaçables par les classes de base	La non-évidence des violations, nécessite de comprendre le contrat de la classe de base
I (ISP)	Les clients ne doivent pas dépendre de méthodes inutilisées	Division des interfaces
D (DIP)	Dépendance aux abstractions, pas aux implémentations concrètes	Injection de dépendances