ตรวจสอบการออกแบบอินเทอร์เฟซ
- 5 นาที
สมมติว่ามีโปรแกรมเมอร์จํานวนมากที่พัฒนาระบบการจัดการไลบรารีและโปรแกรมเมอร์สองคนได้รับมอบหมายให้จัดการหนังสือที่ยืมได้ Mahmud หนึ่งในโปรแกรมเมอร์ออกแบบชั้นเรียนที่เรียกว่า BorrowableBook ด้วยวิธีการสําหรับยืมและส่งคืนหนังสือ Mahmud สร้างวิธีการที่ Borrow ชื่อว่าเพื่อให้ผู้ใช้สามารถยืมหนังสือและวิธีอื่นที่ Return ชื่อว่าเพื่อจัดการการส่งคืน วิธีการเหล่านี้ช่วยให้มั่นใจว่ามีการติดตามความพร้อมใช้งานของหนังสืออย่างเหมาะสมและให้คําติชมที่ชัดเจนแก่ผู้ใช้
Yara นักพัฒนารายอื่นไม่ทราบความพยายามของ Mahmud Yara สร้างคลาสที่คล้ายกัน แต่ใช้มาตรฐานการตั้งชื่อที่แตกต่างกัน เช่น Checkout และGiveBack ความไม่สอดคล้องกันนี้อาจทําให้เกิดความสับสนและความยุ่งยากสําหรับโปรแกรมเมอร์รายอื่นที่ทํางานกับโครงการเนื่องจากจําเป็นต้องเรียนรู้ชื่อวิธีการที่แตกต่างกันสําหรับฟังก์ชันการทํางานที่คล้ายกัน
หากมีการกําหนดวิธีการจัดการหนังสืออย่างต่อเนื่องโปรแกรมเมอร์สามารถเรียนรู้วิธีการใช้งานได้อย่างรวดเร็ว พวกเขาไม่จําเป็นต้องอธิบายวิธีการยืมหรือคืนหนังสือทุกครั้งที่พวกเขาพบชั้นเรียนใหม่ การสร้างมาตรฐานรหัสไว้ด้านหน้าช่วยให้รหัสโครงการของคุณง่ายขึ้นและทําให้ง่ายต่อการบํารุงรักษา
มาตรฐานการเข้ารหัส
การกําหนดมาตรฐานโค้ดหมายถึงการสร้างและปฏิบัติตามชุดของกฎสําหรับการเขียนโค้ด กฎเหล่านี้ช่วยให้โค้ดสอดคล้องกันและง่ายต่อการอ่านทั่วทั้งโครงการ เมื่อทุกคนปฏิบัติตามกฎเดียวกัน โปรแกรมเมอร์ที่แตกต่างกันจะเข้าใจและทํางานกับโค้ดของกันและกันได้ง่ายขึ้น การกําหนดมาตรฐานยังช่วยป้องกันข้อผิดพลาด ปรับปรุงคุณภาพของโค้ด และทําให้ตรวจสอบข้อผิดพลาดได้อย่างรวดเร็ว
การใช้อินเทอร์เฟซสามารถช่วยสร้างการกําหนดมาตรฐานของโค้ด เนื่องจากอินเทอร์เฟซทําหน้าที่เป็นสัญญาสําหรับโค้ด เมื่อคุณกําหนดอินเทอร์เฟซ คุณจะระบุว่าคลาสใดที่ใช้อินเทอร์เฟซนั้นต้องมีวิธีการและคุณสมบัติบางอย่าง การใช้อินเทอร์เฟซยังสามารถช่วยป้องกันโค้ดที่ควบคู่กันอย่างแน่นหนาซึ่งช่วยให้คุณสามารถปฏิบัติตามมาตรฐานการออกแบบได้ดีขึ้น
หลักการออกแบบแบบ SOLID
SOLID เป็นตัวย่อสําหรับหลักการออกแบบห้าประการของการเขียนโปรแกรมเชิงวัตถุและอินเทอร์เฟซเป็นองค์ประกอบสําคัญของหลักการเหล่านี้ หลักการของการออกแบบคือ:
หลักความรับผิดชอบเดี่ยว (SRP): คลาสควรมุ่งเน้นไปที่งานที่ชัดเจนหนึ่งงานและจัดการงานทั้งหมด ดังนั้น คลาสควรเปลี่ยนแปลงเพียงเหตุผลหนึ่งเท่านั้น
หลักเปิด/ปิด (OCP): คลาสควรเปิดสําหรับส่วนขยาย แต่ปิดสําหรับการปรับเปลี่ยน กล่าวอีกนัยหนึ่ง คุณควรสามารถเพิ่มฟังก์ชันการทํางานใหม่ไปยังคลาสโดยไม่ต้องเปลี่ยนโค้ดที่มีอยู่
หลักการทดแทน Liskov (LSP): ประเภทย่อยควรแทนที่ประเภทฐาน กล่าวอีกนัยหนึ่ง ถ้าโปรแกรมถูกเขียนเพื่อทํางานกับวัตถุบางชนิด ชนิดย่อยของวัตถุนั้นควรจะสามารถแทนที่ได้โดยไม่ทําให้เกิดข้อผิดพลาด
หลักการแยกส่วนติดต่อ (ISP): ไม่ควรบังคับให้คลาสขึ้นอยู่กับอินเทอร์เฟซที่พวกเขาไม่ได้ใช้ แต่ควรออกแบบอินเทอร์เฟซเพื่อให้ฟังก์ชันการทํางานที่คลาสต้องการเท่านั้น
หลักการผกผันแบบขึ้นต่อกัน (DIP): แทนที่จะคลาสขึ้นอยู่กับคอมโพเนนต์อื่น ๆ โดยตรง ควรขึ้นอยู่กับอินเทอร์เฟซหรือคลาสนามธรรมที่กําหนดลักษณะการทํางานที่จําเป็น นามธรรมของข้อกําหนดลักษณะการทํางานช่วยให้มีความยืดหยุ่นและโมดูลในโครงการมากขึ้นเนื่องจากการเปลี่ยนแปลงไปยังองค์ประกอบหนึ่งไม่ส่งผลกระทบต่อองค์ประกอบอื่น
ด้วยการทําตามหลักการเหล่านี้ นักพัฒนาซอฟต์แวร์สามารถสร้างซอฟต์แวร์ที่ง่ายต่อการปรับเปลี่ยนทดสอบและบํารุงรักษาด้วยการมีเพศสัมพันธ์ที่คลายตัวและความสอดคล้องระหว่างส่วนประกอบที่ดีกว่า หลักการ SOLID มีการใช้กันอย่างแพร่หลายในการเขียนโปรแกรมเชิงวัตถุและถือเป็นแนวทางปฏิบัติที่ดีที่สุดในการพัฒนาซอฟต์แวร์
เลือกคําตอบที่ดีที่สุดสําหรับแต่ละคําถามด้านล่าง