หลักการผกผันการพึ่งพา (DIP)

Mar 09 2023
หลักการข้อที่ห้าของ SOLID คือหลักการพึ่งพาการผกผัน ซึ่งเรียกโดยย่อว่า DIP หลักการนี้ระบุว่าโมดูลระดับสูงไม่ควรขึ้นอยู่กับโมดูลระดับต่ำ
ภาพประกอบนี้ออกแบบโดย Ugonna Thelma

หลักการข้อที่ห้าของ SOLID คือหลักการพึ่งพาการผกผันซึ่งเรียกโดยย่อว่าDIP

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

สิ่งที่เป็นนามธรรมไม่ควรขึ้นอยู่กับรายละเอียด รายละเอียดควรขึ้นอยู่กับนามธรรม

มาดูกันว่าหลักการนี้พูดว่าอะไรและการพึ่งพาอาศัยกันคืออะไร!

คลาส A ขึ้นอยู่กับคลาส B เพื่อดำเนินการ ดังนั้นคลาส A จึงเป็นคลาสระดับสูง และ B เป็นคลาสระดับต่ำ

นามธรรมคืออะไร?

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

ส่วน ต่อประสานและคลาสนามธรรมเป็นเครื่องมือสำหรับแนวคิดเชิงนามธรรม

ทำไมเราต้องการหลักการผกผันการพึ่งพา ?

กรมทรัพย์สินทางปัญญาช่วยให้คุณสร้างโค้ดที่เชื่อมต่อแบบหลวมๆแทนที่จะเชื่อมต่ออย่างแน่นหนา

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

สมมติว่าคุณกำลังทำงานในโครงการซอฟต์แวร์กับทีมที่ประกอบด้วยผู้พัฒนาส่วนหน้าและส่วนหลัง

BackEndDeveloper.java
FrontEndDeveloper.java

และโครงการต้องการทั้งส่วนหน้าและส่วนหลังในการดำเนินการ

Project.java

คลาสระดับสูงซึ่งก็คือ Project ขึ้นอยู่กับคลาสระดับล่างของ FrontEndDeveloper และ BackEndDeveloper เพื่อทำงานต่อไป และถ้าเราต้องการเปลี่ยนแปลงในคลาสระดับล่าง ก็อาจส่งผลกระทบโดยตรงต่อโครงการที่ใช้คลาสเหล่านั้น

ตัวอย่างเช่น หากมีการเพิ่มเมธอดในคลาส BackEndDeveloper หรือใช้ Python แทน Java สุดท้ายแล้ว เราต้องใช้การเปลี่ยนแปลงเหล่านี้กับคลาส Project ด้วย

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

ทางออกคืออะไร?

มาสร้างอินเทอร์เฟซสำหรับนักพัฒนาทุกคนที่มีวิธี "พัฒนา" และโปรแกรมเมอร์แต่ละคนใช้วิธีนั้นตามสายงานของตนเอง

Developer.java
BackEndDeveloper.java
FrontEndDeveloper.java

ตอนนี้คลาส Project ของเราสามารถรับรายชื่อผู้พัฒนาและเรียกใช้เมธอด "พัฒนา" โดยไม่ต้องพึ่งพาใดๆ

Project.java

เราได้ปฏิบัติตามหลักการของกรมทรัพย์สินทางปัญญา

ด้วยวิธีนี้ ไม่สำคัญว่าโปรแกรมเมอร์จะเป็นแบ็กเอนด์ ฟรอนต์เอนด์ หรือนักพัฒนามือถือ และคลาส Project ของเราจะไม่มีการพึ่งพาคลาสระดับล่างหรือเมธอดของคลาสเหล่านั้น