SOLID — จากศูนย์ถึงมันฝรั่ง 4

วันนี้ผมจะอธิบายเกี่ยวกับหลักการแยกส่วนต่อประสาน (ISP)หลักการนี้คล้ายกับLSP มาก ดังนั้นอย่าสับสนกับLSP ผมจะอธิบายความแตกต่างระหว่างสองหลักการนี้

LSPควบคุมความสัมพันธ์ระหว่างคลาสพาเรนต์และคลาสย่อย (เช่น ความสัมพันธ์แบบลำดับชั้น) มันบอกวิธีการใช้ ISP ควบคุมความสัมพันธ์ระหว่างคลาสพาเรนต์และไคลเอ็นต์ (เช่น ความสัมพันธ์ระหว่างผู้ผลิต/ผู้บริโภค) มันบอกคุณว่าเมื่อใดควรใช้

หลักการแยกส่วนต่อประสาน(Interface Segregation Principle - ISP) คืออะไร ISPระบุว่าเราควรออกแบบส่วนต่อประสานที่เฉพาะเจาะจงกับความต้องการของไคลเอนต์หรือชุดของลูกค้า แทนที่จะสร้างอินเทอร์เฟซขนาดใหญ่ที่ไม่จำเป็นสำหรับไคลเอ็นต์บางราย

หลักการแยกอินเทอร์เฟซ (ISP): ไคลเอนต์ไม่ควรถูกบังคับให้ขึ้นอยู่กับอินเทอร์เฟซที่ไม่ได้ใช้

ไปที่การใช้งาน เรามีอินเทอร์เฟซStudentActivitiesที่เรียกว่ากำหนดวิธีการต่าง ๆ ที่เกี่ยวข้องกับกิจกรรมนักเรียน:

interface StudentActivities {
    fun joinClub(club: String)
    fun joinSportsTeam(sportsTeam: String)
    fun attendEvent(event: String)
    fun volunteerForEvent(event: String)
    fun joinStudyGroup(subject: String)
}

class Student : StudentActivities {
    override fun joinClub(club: String) {
        // join the specified club
    }

    override fun joinSportsTeam(sportsTeam: String) {
        // join the specified sports team
    }

    override fun attendEvent(event: String) {
        // attend the specified event
    }

    override fun volunteerForEvent(event: String) {
        // volunteer for the specified event
    }

    override fun joinStudyGroup(subject: String) {
        // join the specified study group
    }
}

ให้ refactor เป็นตัวอย่างที่ถูกต้องตอนนี้ เราสามารถแบ่งส่วนStudentActivitiesต่อประสานออกเป็นส่วนต่อประสานที่เล็กลงและมุ่งเน้นมากขึ้นซึ่งลูกค้าใช้งานได้ง่ายขึ้น:

interface ClubActivities {
    fun joinClub(club: String)
}

interface SportsActivities {
    fun joinSportsTeam(sportsTeam: String)
}

interface EventActivities {
    fun attendEvent(event: String)
    fun volunteerForEvent(event: String)
}

interface StudyGroupActivities {
    fun joinStudyGroup(subject: String)
}

class Student : ClubActivities, SportsActivities, EventActivities, StudyGroupActivities {
    override fun joinClub(club: String) {
        // join the specified club
    }

    override fun joinSportsTeam(sportsTeam: String) {
        // join the specified sports team
    }

    override fun attendEvent(event: String) {
        // attend the specified event
    }

    override fun volunteerForEvent(event: String) {
        // volunteer for the specified event
    }

    override fun joinStudyGroup(subject: String) {
        // join the specified study group
    }
}

สิ่งนี้เป็นไปตามหลักการแยกส่วนต่อประสานเนื่องจากไคลเอนต์ที่ต้องการเพียงชุดย่อยเฉพาะของกิจกรรมที่กำหนดในอินเทอร์เฟซสามารถพึ่งพาเฉพาะส่วนต่อประสานที่เล็กกว่าที่สอดคล้องกัน แทนที่จะต้องขึ้นอยู่กับส่วนต่อประสานที่ใหญ่กว่าและเหนียวแน่นน้อยกว่าซึ่งมีเมธอดที่พวกเขาไม่ทำ' ไม่ต้องการ

ขอบคุณที่สละเวลาอ่านบทความนี้ ฉันหวังว่างานเขียนของฉันจะได้รับข้อมูลและกระตุ้นความคิด ฉันจะอธิบายเกี่ยวกับหลักการพึ่งพาการผกผัน (DIP)ในบทความหน้า ขอให้มีความสุขในการเข้ารหัสกับทุกท่าน

บทความก่อนหน้านี้เกี่ยวกับ SOLID :

หลักการความรับผิดชอบเดียว (SRP) :https:///arpalar-tech/solid-from-zero-to-potato-e7b5cfe8c7a1

หลักการเปิด/ปิด (OCP): https:///arpalar-tech/solid-from-zero-to-potato-2-5a4c17bd8ec8

หลักการทดแทนลิสคอฟ (LSP): https:///arpalar-tech/solid-from-zero-to-potato-3-94d6f63dbbfe