Welke van de SOLID-principes vind je het moeilijkst in de praktijk toe te passen?

Barbara Liskov's vervangingsprincipe (LSP).

De moeilijkheid ligt in het feit dat het schenden van LSP niet altijd meteen duidelijk is en pas aan het licht komt bij het gebruik van subklassen in een context waar het gedrag van de basisklasse wordt verwacht. Dit vereist een diepgaand begrip van het beoogde gedrag van de basisklasse en grondige tests.

Voorbeeld van schending:

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) // Schending van LSP: het wijzigen van de breedte beïnvloedt de hoogte
    }

    override func setHeight(_ height: Double) {
        super.setHeight(height)
        super.setWidth(height) // Schending van LSP: het wijzigen van de hoogte beïnvloedt de breedte
    }
}

Als Square wordt gebruikt waar Rectangle wordt verwacht, zal het gedrag van Square bij het wijzigen van slechts één zijde (breedte of hoogte) leiden tot onvoorspelbare resultaten, omdat de basisklasse Rectangle dat gedrag niet heeft.

Om schendingen van LSP te voorkomen, is het vaak nodig om klassendiagrammen te herzien, compositie in plaats van overerving te gebruiken of meer abstracte interfaces/protocollen te introduceren. Dit kan de complexiteit van het ontwerp in de beginfase vergroten.

Vergelijkingstabel:

SOLID-principe	Korte beschrijving	Belangrijkste uitdaging bij het toepassen van LSP
S (SRP)	Eén klasse - één reden voor verandering	Het vinden van de "enige reden"
O (OCP)	Open voor uitbreiding, gesloten voor modificatie	Correct gebruik van abstracties
L (LSP)	Subklassen moeten vervangbaar zijn door basisklassen	Onzichtbaarheid van schendingen, begrip van contract van basisklasse vereist
I (ISP)	Klanten mogen niet afhankelijk zijn van niet-gebruikte methoden	Interface-opdeling
D (DIP)	Afhankelijkheid van abstracties, niet van concrete implementaties	Dependency injection