SOLID — ゼロからポテトまで 3

Liskov Substitution Principle (LSP)について

今日はこの記事でLiskov Substitution Principle (LSP)について説明します.

LSPについての詳細な説明に移る前に、LSP が日常業務でどのように役立つかを知っておく必要があります。LSP は、適切な継承階層をモデル化するのに役立ちます。これは、オープン/クローズの原則に準拠しないモデル階層を防ぐのに役立ちます。Liskov Substitution Principleに準拠する継承モデルは、暗黙のうちにOpen/Closed Principleに従います。

コーディングにジャンプします。ところで、kotlin について理解していなくても、心配する必要はありません。LSP はどの言語でも実装できるので、好きな言語で試すことができます。

学生の成績に基づいて GPA を計算するメソッドをStudent持つクラスがあります。calculateGPA

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
    }
}

LSPに準拠するために、クラスの設計を変更できます。これを行う 1 つの方法は、メソッドGPAを持つ という名前の新しいインターフェイスを作成することです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
    }
}

これはLiskov Substitution Principleに準拠しています。これは、型のオブジェクトを期待するコードはオブジェクトまたはオブジェクトのGPAいずれかを渡すことができ、メソッドの動作は両方のオブジェクトで一貫しているためです。StudentHonorsStudentcalculate

動作を別のインターフェイスに分離することでcalculateGPA、そのインターフェイスを実装するサブクラスが、そのインターフェイス タイプの他のオブジェクトと一貫して動作するようにします。

この記事を読んでいただきありがとうございます。私の執筆が有益で示唆に富むものであったことを願っています。