Sobes.tech
Senior

Care dintre principiile SOLID îți este cel mai dificil să le aplici în practică?

sobes.tech AI

Răspuns de la AI

Principiul substituției lui Barbara Liskov (LSP).

Dificultatea constă în faptul că încălcarea LSP nu este întotdeauna evidentă la prima vedere și poate fi descoperită doar atunci când se utilizează subclase într-un context în care se așteaptă comportamentul clasei de bază. Acest lucru necesită o înțelegere profundă a comportamentului prevăzut al clasei de bază și teste riguroase.

Exemplu de încălcare:

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) // Încălcarea LSP: schimbarea lățimii afectează înălțimea
    }

    override func setHeight(_ height: Double) {
        super.setHeight(height)
        super.setWidth(height) // Încălcarea LSP: schimbarea înălțimii afectează lățimea
    }
}

Dacă se folosește Square acolo unde se așteaptă Rectangle, comportamentul Square la schimbarea unei singure părți (lățime sau înălțime) va duce la rezultate imprevizibile, deoarece clasa de bază Rectangle nu are astfel de comportamente.

Pentru a preveni încălcările LSP, este adesea necesar să se regândească ierarhiile de clase, să se utilizeze compoziția în loc de moștenire sau să se introducă interfețe/protocoluri mai abstracte. Acest lucru poate adăuga complexitate în proiectare în etapele inițiale.

Tabel comparativ:

Principiul SOLID Descriere scurtă Principala dificultate în aplicarea LSP
S (SRP) O clasă - un motiv pentru schimbare Găsirea "singurului motiv"
O (OCP) Deschis pentru extindere, închis pentru modificare Utilizarea corectă a abstracțiilor
L (LSP) Subclasele trebuie să fie substituibile claselor de bază Necurățenia încălcărilor, necesită înțelegerea contractului clasei de bază
I (ISP) Clienții nu trebuie să depindă de metode neutilizate Divizarea interfețelor
D (DIP) Dependența de abstracții, nu de implementări concrete Injecția de dependențe