ทำไมโปรแกรมเมอร์ต้องการแยกการใช้งานจากส่วนต่อประสาน


18

รูปแบบการออกแบบบริดจ์แยกการใช้งานจากอินเตอร์เฟสของโปรแกรม

ทำไมข้อได้เปรียบนี้?


เพื่อป้องกันสิ่งที่เป็นนามธรรม
SK-logic

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

คำตอบ:


35

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

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


23

นอกเหนือจากคำตอบของ Daniel แล้วการแยกส่วนต่อประสานจากการใช้งานผ่านแนวคิดเช่นpolymorphismช่วยให้คุณสร้างการใช้งานหลายอย่างของส่วนต่อประสานเดียวกันที่ทำสิ่งที่คล้ายกันในรูปแบบต่างๆ

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

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

หากคุณพึ่งพาการนำไปใช้งานโดยตรงคุณจะต้องเขียนรูทีนที่แตกต่างกันสองชุดเพื่อบันทึกข้อมูลเดียวกันลงในไฟล์หรือส่งผ่านเครือข่าย แต่ถ้าคุณมีส่วนต่อประสานกระแสคุณสามารถสร้างการใช้งานที่แตกต่างกันสองอย่างของมัน ( FileStreamและNetworkStream) ซึ่งสรุปรายละเอียดเฉพาะของการส่งข้อมูลที่จำเป็นต้องไปแล้วคุณต้องเขียนรหัสที่เกี่ยวข้องกับการบันทึกไฟล์เพียงครั้งเดียว . ทันใดคุณSaveToFileและSendOverNetworkกิจวัตรของคุณนั้นง่ายกว่ามากพวกเขาเพียงแค่ตั้งค่าสตรีมของประเภทที่เหมาะสมและส่งผ่านไปยังSaveDataรูทีนซึ่งยอมรับอินเตอร์เฟสของกระแสข้อมูล - ไม่จำเป็นต้องสนใจประเภทใดตราบใดที่มันสามารถทำงานได้ การดำเนินการเขียน - และบันทึกข้อมูลไปยังสตรีม

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


1
นี่เป็นหนึ่งในคุณสมบัติที่แข็งแกร่งที่สุดของ OOP ฉันรักมันมาก ...
Radu Murzea

1
รูปแบบนี้แตกต่างกันอย่างไรโดยใช้อินเตอร์เฟสธรรมดา
vainolo

@Vainolo: ช่วยด้วยการนำรหัสมาใช้ใหม่ แม้ว่าคุณจะมีสตรีมหลายประเภทก็ตามพวกเขาทั้งหมดจะทำสิ่งต่าง ๆ มากมายเหมือนกัน หากคุณเริ่มต้นด้วยIStreamส่วนต่อประสานคุณจะต้องบูรณาการทุกฟังก์ชั่นใหม่สำหรับทุกกระแส แต่ถ้าคุณเริ่มต้นด้วยคลาสสตรีม abstract พื้นฐานคลาสนั้นสามารถเก็บสถานะทั่วไปและฟังก์ชันทั้งหมดไว้แล้วปล่อยให้ลูกหลานใช้คุณสมบัติที่แตกต่างกัน
Mason Wheeler

2
@RaduMurzea สิ่งนี้ไม่เฉพาะกับ OOP คลาสประเภทช่วยให้คุณทำสิ่งเดียวกันในแบบ OOP ที่ไม่สมบูรณ์
เวส

@ แน่นอนว่าแค่อยากจะพูดแบบเดียวกันแล้วฉันจะอ่านความคิดเห็นของคุณ
jhegedus

4

คุณมีคำถามสองข้อที่แตกต่างกันจริงๆที่นี่แม้ว่าพวกเขาจะเกี่ยวข้องกัน

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

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

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

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

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

ฟังดูตรงไปตรงมา แต่ในทางปฏิบัติมันซับซ้อน

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

ดังนั้นสมมติว่าคุณต้องการเขียนโปรแกรมเสริมไปยังโปรแกรมประมวลผลคำ แต่คุณต้องการให้โปรแกรมประมวลผลคำหลายตัวทำงานได้ คุณอาจสร้างอินเทอร์เฟซที่เป็นนามธรรมจากการทำงานของ word processor ตามที่คุณต้องการ (ซึ่งต้องใช้งานได้โดยแต่ละ word processor เนื่องจากคุณไม่สามารถเปลี่ยนได้) และ implementer หนึ่งของ interface นั้นสำหรับ word processor แต่ละตัวที่คุณต้องการสนับสนุน แอปพลิเคชันของคุณสามารถเรียกใช้อินเทอร์เฟซนั้นและไม่ต้องกังวลกับรายละเอียดของโปรแกรมประมวลผลคำแต่ละคำ

จริงๆแล้วมันมีรายละเอียดมากกว่านั้นเล็กน้อยเนื่องจากแต่ละคลาสอาจเป็นลำดับชั้นของชั้นเรียน (ดังนั้นอาจไม่เพียง แต่เป็นโปรแกรมประมวลผลคำที่เป็นนามธรรม แต่เป็นเอกสารนามธรรมบทคัดย่อ TextSelection และอื่น ๆ ที่มีการใช้งานที่เป็นรูปธรรมสำหรับแต่ละ) ความคิดเดียวกัน

มันเป็นเหมือนซุ้มยกเว้นในกรณีนี้เลเยอร์สิ่งที่เป็นนามธรรมจะเน้นที่การให้อินเทอร์เฟซเดียวกันกับระบบพื้นฐานหลายระบบ

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.