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

Apr 02 2023
เกี่ยวกับหลักการพึ่งพาการผกผัน (DIP) ในบทความนี้ บทความนี้จะเป็นบทความสุดท้ายเกี่ยวกับ SOLID
วันนี้ฉันจะอธิบายเกี่ยวกับหลักการพึ่งพาการผกผัน (DIP) ต่อในบทความนี้ เราจะคุ้นเคยกับหลักการอื่นๆ ใน SOLID เพราะแม้ว่าเราจะไม่รู้เกี่ยวกับหลักการของ SOLID เราก็สามารถเรียนรู้ได้จากโค้ดของรุ่นพี่ บทความสื่อกลางต่างๆ และแบบฝึกหัดต่างๆ แต่คุณจะไม่ค่อยได้ยินว่า Dependency Inversion คืออะไร และเราควรใช้อย่างไรและทำไมเราจึงควรใช้

วันนี้ฉันจะอธิบายเกี่ยวกับหลักการพึ่งพาการผกผัน (DIP)ต่อในบทความนี้ เราจะคุ้นเคยกับหลักการอื่นๆ ในSOLIDเพราะแม้ว่าเราจะไม่รู้เกี่ยวกับ หลักการของ SOLIDเราก็สามารถเรียนรู้ได้จากโค้ดของรุ่นพี่ บทความสื่อกลางต่างๆ และแบบฝึกหัดต่างๆ แต่คุณจะไม่ค่อยได้ยินว่าDependency Inversion คืออะไร และเราควรใช้อย่างไรและทำไมเราจึงควรใช้

อย่างไรก็ตาม หากคุณทำงานเป็นนักพัฒนา Android อยู่แล้ว อย่าสับสนกับDependency Injection คุณจะคุ้นเคยกับคลังยอดนิยม Dagger, Hilt และ Koin สองคนนี้แตกต่างกันมาก ดังนั้นโปรดใช้ความระมัดระวังเมื่อคุณอธิบายโดยเฉพาะอย่างยิ่งในการสัมภาษณ์

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

หลักการผกผันการพึ่งพา (DIP): โมดูลระดับสูงไม่ควรขึ้นอยู่กับโมดูลระดับต่ำ ทั้งสองควรขึ้นอยู่กับสิ่งที่เป็นนามธรรม

ให้ฉันอธิบายคุณด้วยการติดตั้งโค้ดอย่างง่าย หลังจากนั้นคุณจะเข้าใจเกี่ยวกับDIP มากขึ้น ตามปกติให้เริ่มต้นด้วยStudentคลาสที่มีการพึ่งพาTeacherคลาสเพื่อใช้งานฟังก์ชันบางอย่าง:

class Student(private val teacher: Teacher) {
    fun askQuestion(question: String) {
        teacher.answerQuestion(question)
    }
}

ดังนั้นให้ refactor ปฏิบัติตามDIPเราสามารถแนะนำสิ่งที่เป็นนามธรรมระหว่าง คลาส StudentและTeacher:

interface QuestionAnswerer {
    fun answerQuestion(question: String)
}

class Teacher : QuestionAnswerer {
    override fun answerQuestion(question: String) {
        // answer the specified question
    }
}

class Student(private val questionAnswerer: QuestionAnswerer) {
    fun askQuestion(question: String) {
        questionAnswerer.answerQuestion(question)
    }
}

สิ่งนี้เป็นไปตาม DIP เนื่องจากStudentตอนนี้คลาสขึ้นอยู่กับสิ่งที่เป็นนามธรรม ( QuestionAnswerer) มากกว่าการใช้งานที่เป็นรูปธรรม ( Teacher) ซึ่งช่วยให้มีความยืดหยุ่นและขยายได้มากขึ้น เนื่องจากคลาสใดๆ ที่ใช้QuestionAnswererอินเทอร์เฟซสามารถใช้เป็นการอ้างอิงสำหรับStudentคลาสนั้น ไม่ใช่แค่Teacherคลาส เดียว

หลังจากดูเวอร์ชันที่รีแฟคเตอร์แล้ว ฉันหวังว่าคุณจะเข้าใจว่าเหตุใดเราจึงควรใช้Dependency Inversionด้วย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

หลักการแยกอินเทอร์เฟซ (ISP):https:///arpalar-tech/solid-from-zero-to-potato-4-d1d9b42c3a78