ทำความเข้าใจกับ“ การเขียนโปรแกรมไปยังส่วนต่อประสาน”

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

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

ตัวอย่างทั่วไปใน Java คือการใช้:

List myList = new ArrayList();ArrayList myList = new ArrayList();แทน

ฉันมีคำถามสองข้อเกี่ยวกับเรื่องนี้:

1. ฉันต้องการให้แน่ใจว่าฉันเข้าใจถึงประโยชน์หลักของวิธีนี้ ฉันคิดว่าประโยชน์ส่วนใหญ่มีความยืดหยุ่น การประกาศวัตถุเป็นข้อมูลอ้างอิงระดับสูงมากกว่าการนำไปปฏิบัติอย่างเป็นรูปธรรมช่วยให้มีความยืดหยุ่นและบำรุงรักษาได้มากขึ้นตลอดวงจรการพัฒนาและตลอดทั้งรหัส ถูกต้องหรือไม่ ความยืดหยุ่นเป็นประโยชน์หลักหรือไม่?

2. มีวิธีเพิ่มเติมในการ 'เขียนโปรแกรมไปยังส่วนต่อประสาน' หรือไม่? หรือ "การประกาศตัวแปรเป็นอินเตอร์เฟสแทนที่จะใช้อย่างเป็นรูปธรรม" เป็นการนำแนวคิดนี้ไปปฏิบัติเท่านั้น

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

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

นี้ไม่ถูกต้อง หรืออย่างน้อยก็ไม่ถูกต้องทั้งหมด

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

แนวคิดหลักคือโดเมนเปลี่ยนช้ากว่าซอฟต์แวร์ไม่มาก สมมติว่าคุณมีซอฟต์แวร์เพื่อติดตามรายการขายของชำของคุณ ในยุค 80 ซอฟต์แวร์นี้จะทำงานกับบรรทัดคำสั่งและไฟล์แฟล็ตบางไฟล์บนฟลอปปี้ดิสก์ จากนั้นคุณจะได้รับ UI จากนั้นคุณอาจใส่รายการลงในฐานข้อมูล หลังจากนั้นอาจย้ายไปที่คลาวด์หรือโทรศัพท์มือถือหรือการรวม Facebook

หากคุณออกแบบรหัสของคุณโดยเฉพาะเกี่ยวกับการใช้งาน (ฟลอปปี้ดิสก์และบรรทัดคำสั่ง) คุณจะไม่พร้อมสำหรับการเปลี่ยนแปลง หากคุณออกแบบรหัสของคุณรอบ ๆ อินเทอร์เฟซ (จัดการรายการร้านขายของชำ) การใช้งานนั้นสามารถเปลี่ยนแปลงได้ฟรี

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

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

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

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

ตัวอย่างที่สำคัญของเรื่องนี้คือโปรแกรมที่เขียนขึ้นสำหรับ Windows WinAPI เป็นอินเทอร์เฟซ แต่มีหลายคนที่ใช้ลูกเล่นที่ทำงานได้เนื่องจากการใช้งานเฉพาะใน Windows 95 กล่าวว่าเทคนิคเหล่านี้อาจทำให้โปรแกรมของพวกเขาเร็วขึ้นหรืออนุญาตให้พวกเขาทำสิ่งต่าง ๆ โดยใช้โค้ดน้อยกว่าที่จำเป็น แต่เทคนิคเหล่านี้ก็หมายความว่าโปรแกรมจะทำงานล้มเหลวใน Windows 2000 เพราะ API นั้นมีการใช้งานที่แตกต่างกัน หากโปรแกรมนั้นมีความสำคัญเพียงพอ Microsoft อาจดำเนินการต่อไปและเพิ่มการแฮ็กบางส่วนเพื่อให้โปรแกรมสามารถทำงานต่อไปได้ แต่ค่าใช้จ่ายนั้นเพิ่มขึ้นจากความซับซ้อนที่เพิ่มขึ้น (พร้อมปัญหาที่ตามมาทั้งหมด) ของรหัส Windows นอกจากนี้ยังทำให้ชีวิตเป็นเรื่องยากยิ่งขึ้นสำหรับผู้คนในไวน์เพราะพวกเขาพยายามนำ WinAPI มาใช้ด้วยเช่นกัน แต่พวกเขาสามารถอ้างถึงเอกสารประกอบสำหรับวิธีการทำเช่นนี้

ฉันสามารถพูดคุยเกี่ยวกับประสบการณ์ส่วนตัวของฉันเท่านั้นเพราะสิ่งนี้ไม่เคยสอนฉันอย่างเป็นทางการเช่นกัน

จุดแรกของคุณถูกต้อง ความยืดหยุ่นที่ได้รับนั้นมาจากการที่ไม่สามารถเรียกใช้รายละเอียดการใช้งานของคลาสที่ไม่ได้ตั้งใจซึ่งไม่ควรเรียกใช้โดยไม่ตั้งใจ

ตัวอย่างเช่นพิจารณาILoggerอินเทอร์เฟซที่ใช้งานในปัจจุบันเป็นLogToEmailLoggerคลาสที่เป็นรูปธรรม LogToEmailLoggerระดับ exposes ทุกILoggerวิธีการและคุณสมบัติ sysAdminEmailแต่ยังเกิดขึ้นจะมีคุณสมบัติการใช้งานที่เฉพาะเจาะจง

sysAdminEmailเมื่อคนตัดไม้ของคุณจะถูกใช้ในการสมัครของคุณก็ไม่ควรจะเป็นความกังวลของรหัสบริโภคเพื่อตั้งค่า ควรตั้งค่าคุณสมบัตินี้ในระหว่างการตั้งค่าตัวบันทึกและควรปิดบังจากโลก

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

ในแง่นี้การเขียนโปรแกรมเพื่อติดต่อผ่อนคลายการมีเพศสัมพันธ์

เกี่ยวกับประเด็นที่สองของคุณ: อีกเหตุผลที่ฉันได้เห็นการเขียนโค้ดให้อินเทอร์เฟซคือการลดความซับซ้อนของรหัส

ตัวอย่างเช่นสมมติว่าผมมีเกมที่มีอินเตอร์เฟซที่ดังต่อไปนี้I2DRenderable, ,I3DRenderable IUpdateableไม่ใช่เรื่องแปลกสำหรับส่วนประกอบของเกมเดียวที่มีเนื้อหาที่แสดงได้ทั้งแบบ 2D และ 3D ส่วนประกอบอื่น ๆ อาจเป็น 2D เท่านั้นและ 3D อื่น ๆ เท่านั้น

หากการแสดงผลแบบ 2D จะกระทำโดยโมดูลหนึ่งแล้วมันทำให้ความรู้สึกให้มันรักษาคอลเลกชันของI2DRenderables มันไม่สำคัญว่าวัตถุในคอลเลกชันของมันจะเป็นI3DRenderableหรือIUpdatebleเป็นโมดูลอื่น ๆ จะรับผิดชอบในการรักษาด้านเหล่านั้นของวัตถุ

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

ในแง่นี้การเขียนโค้ดให้อินเทอร์เฟซทำให้ความซับซ้อนต่ำโดยแยกข้อกังวลออก

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

ฉันจะบอกว่าการเขียนโปรแกรมไปยังอินเตอร์เฟสเป็นแนวคิดที่กว้างขึ้น REST APIs ที่ได้รับความนิยมในขณะนี้ที่มีอยู่ในเว็บไซต์จำนวนมากเป็นอีกตัวอย่างของแนวคิดที่กว้างขึ้นของการเขียนโปรแกรมไปยังอินเทอร์เฟซในระดับที่สูงขึ้น โดยการสร้างเลเยอร์ระหว่างการทำงานภายในของโค้ดและโลกภายนอก (ผู้คนบนอินเทอร์เน็ตโปรแกรมอื่น ๆ หรือแม้แต่ส่วนอื่น ๆ ของโปรแกรมเดียวกัน) คุณสามารถเปลี่ยนแปลงอะไรก็ได้ในโค้ดของคุณตราบใดที่คุณไม่เปลี่ยนโลกภายนอก คาดหวังว่าจะมีการกำหนดอินเทอร์เฟซหรือสัญญาที่คุณตั้งใจจะให้เกียรติ

จากนั้นจะให้ความยืดหยุ่นแก่คุณในการปรับเปลี่ยนรหัสภายในของคุณในขณะที่ไม่ต้องบอกสิ่งอื่น ๆ ทั้งหมดที่ขึ้นอยู่กับส่วนต่อประสานของมัน

นอกจากนี้ยังหมายความว่ารหัสของคุณควรมีเสถียรภาพมากขึ้น ด้วยการเกาะติดอินเทอร์เฟซคุณไม่ควรทำลายรหัสของคนอื่น เมื่อคุณต้องเปลี่ยนอินเทอร์เฟซจริง ๆ แล้วคุณสามารถปล่อยรุ่นสำคัญรุ่นใหม่ (1.abc ถึง 2.xyz) ของ API ซึ่งเป็นสัญญาณว่ามีการเปลี่ยนแปลงในอินเทอร์เฟซของเวอร์ชันใหม่

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

การเปรียบเทียบโลกแห่งความจริงอาจช่วย:

ปลั๊กไฟหลักในส่วนต่อประสาน
ใช่; ที่ปลายสายไฟจากทีวีวิทยุเครื่องดูดฝุ่นเครื่องซักผ้า ฯลฯ

อุปกรณ์ใด ๆ ที่มีปลั๊กหลัก (เช่นใช้ส่วนต่อประสาน "มีปลั๊กไฟหลัก") สามารถรักษาได้ในลักษณะเดียวกัน พวกเขาทั้งหมดสามารถเสียบเข้ากับเต้ารับบนผนังและสามารถดึงพลังงานจากซ็อกเก็ตนั้น

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

นั่นคือสิ่งที่อินเตอร์เฟซนำมาให้คุณ
Unifiedพฤติกรรมที่สามารถดำเนินการได้โดยหลายชั้นเรียนแตกต่างกันของวัตถุโดยไม่จำเป็นต้องมีภาวะแทรกซ้อนของมรดก

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

ในสถาปัตยกรรมซอฟต์แวร์มีขอบเขตธรรมชาติที่หลากหลาย ตัวอย่างทั่วไป ได้แก่

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

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

ผลที่ตามมาของสิ่งนี้คือ:

• คอมโพเนนต์ภายนอกสามารถแลกเปลี่ยนได้ตราบใดที่ใช้ข้อกำหนด
• จุดธรรมชาติสำหรับการทดสอบหน่วยเพื่อตรวจสอบพฤติกรรมที่ถูกต้อง
• การทดสอบการรวมเป็นสิ่งสำคัญ - ข้อกำหนดเฉพาะไม่ชัดเจนหรือไม่?
• ในฐานะนักพัฒนาคุณมีโลกแห่งความกังวลน้อยลงเมื่อทำงานในภารกิจเฉพาะ

ในขณะที่สิ่งเหล่านี้ส่วนใหญ่สามารถเกี่ยวข้องกับคลาสและอินเทอร์เฟซมันเป็นสิ่งสำคัญที่จะตระหนักว่ามันยังเกี่ยวข้องกับรูปแบบข้อมูล, โปรโตคอลเครือข่ายและในลักษณะทั่วไปที่ทำงานกับนักพัฒนาหลาย ๆ