SOLID – Von Null bis Kartoffel 3

Über das Liskov-Substitutionsprinzip (LSP)

Heute werde ich in diesem Artikel weiter das Liskov-Substitutionsprinzip (LSP) erläutern . Dort können Sie meinen vorherigen Artikel über das Prinzip der Einzelverantwortung und das Offen/Geschlossen-Prinzip (OCP) lesen .

Bevor wir zu den Einzelheiten über LSP übergehen , sollten wir wissen, wie hilfreich LSP bei unserer täglichen Arbeit ist. LSP hilft uns dabei, gute Vererbungshierarchien zu modellieren. Es hilft uns, Modellhierarchien zu vermeiden, die nicht dem Open/Closed-Prinzip entsprechen. Jedes Vererbungsmodell, das sich an das Liskov-Substitutionsprinzip hält , folgt implizit dem Open/Closed-Prinzip .

Lassen Sie übrigens zur Codierung springen, wenn Sie Kotlin nicht verstehen, machen Sie sich keine Sorgen, LSP kann es in jeder Sprache implementieren, so dass Sie es mit Ihrer Lieblingssprache versuchen können.

Wir haben eine StudentKlasse, die eine calculateGPAMethode hat, die den GPA basierend auf den Noten des Schülers berechnet:

open class Student(val grades: List<Double>) {
    open fun calculateGPA(): Double {
        // calculate the GPA based on the grades
    }
}

class HonorsStudent(grades: List<Double>) : Student(grades) {
    override fun calculateGPA(): Double {
        // calculate the GPA based on a different set of rules for honors students
    }
}

Um das LSP einzuhalten , können wir das Design der Klassen ändern. Eine Möglichkeit, dies zu tun, besteht darin, eine neue Schnittstelle mit dem Namen zu erstellen, die eine Methode GPAhat :calculate

interface GPA {
    fun calculate(): Double
}

open class Student(val grades: List<Double>) : GPA {
    override fun calculate(): Double {
        // calculate the GPA based on the grades
    }
}

class HonorsStudent(grades: List<Double>) : GPA {
    override fun calculate(): Double {
        // calculate the GPA based on a different set of rules for honors students
    }
}

Dies entspricht dem Liskov-Substitutionsprinzip, da jeder Code, der ein Objekt vom Typ erwartet, entweder ein Objekt oder ein Objekt GPAübergeben werden kann und das Verhalten der Methode über beide Objekte hinweg konsistent ist.StudentHonorsStudentcalculate

Indem wir das Verhalten in eine separate Schnittstelle aufteilen calculateGPA, stellen wir sicher, dass sich jede Unterklasse, die diese Schnittstelle implementiert, konsistent mit anderen Objekten dieses Schnittstellentyps verhält.

Vielen Dank, dass Sie sich die Zeit genommen haben, diesen Artikel zu lesen. Ich hoffe, dass mein Schreiben informativ und zum Nachdenken anregend war.