บางครั้งในระหว่างกระบวนการพัฒนาเราจะพบว่าอินเทอร์เฟซที่ลูกค้าต้องการและอินเทอร์เฟซที่ให้ไว้นั้นไม่เข้ากัน เราไม่สามารถแก้ไขอินเทอร์เฟซไคลเอ็นต์ด้วยเหตุผลพิเศษ ในกรณีนี้เราจำเป็นต้องปรับให้เข้ากับอินเทอร์เฟซที่มีอยู่และคลาสที่เข้ากันไม่ได้ซึ่งต้องใช้โหมดอะแดปเตอร์ ด้วยอะแดปเตอร์เราสามารถใช้มันได้โดยไม่ต้องแก้ไขรหัสเก่าซึ่งเป็นความสามารถของอะแดปเตอร์
โหมดการปรับตัวสามารถใช้เพื่อปรับตัวระหว่างอินเทอร์เฟซที่มีอยู่และคลาสที่เข้ากันไม่ได้ วัตถุที่ใช้โหมดนี้เรียกอีกอย่างว่า wrappers เพราะพวกเขาห่อวัตถุอื่นด้วยอินเทอร์เฟซใหม่
บนพื้นผิวโหมดอะแดปเตอร์เป็นเหมือนโหมดลักษณะที่ปรากฏ พวกเขาทั้งหมดจำเป็นต้องห่อวัตถุอื่น ๆ และเปลี่ยนอินเทอร์เฟซที่แสดง ความแตกต่างระหว่างทั้งสองคือวิธีที่พวกเขาเปลี่ยนอินเทอร์เฟซ องค์ประกอบลักษณะที่ปรากฏนำเสนออินเทอร์เฟซที่เรียบง่ายซึ่งไม่ได้ให้ตัวเลือกเพิ่มเติมและบางครั้งก็มีสมมติฐานบางอย่างเพื่ออำนวยความสะดวกในการทำงานร่วมกัน อะแดปเตอร์แปลงอินเทอร์เฟซหนึ่งไปยังอีกอินเตอร์เฟสซึ่งจะไม่กรองความสามารถบางอย่างและจะไม่ทำให้อินเทอร์เฟซง่ายขึ้น หากระบบไคลเอนต์ API ไม่พร้อมใช้งานอะแดปเตอร์จะต้องใช้
ทฤษฎีพื้นฐาน
โหมดอะแดปเตอร์: แปลงอินเทอร์เฟซเป็นอินเทอร์เฟซที่ลูกค้าต้องการโดยไม่ต้องแก้ไขรหัสไคลเอนต์เพื่อให้รหัสที่เข้ากันไม่ได้สามารถทำงานร่วมกันได้
อะแดปเตอร์ส่วนใหญ่ประกอบด้วย 3 บทบาท:
(1) ไคลเอนต์: คลาสที่เรียกอินเทอร์เฟซ
(2) อะแดปเตอร์: คลาสที่ใช้เชื่อมต่ออินเทอร์เฟซไคลเอนต์และอินเทอร์เฟซให้บริการ
(3) อะแดปเตอร์: ให้บริการ แต่ไม่เข้ากันกับข้อกำหนดส่วนต่อประสานไคลเอนต์
การใช้โหมดอะแดปเตอร์
1. อะแดปเตอร์ที่ง่ายที่สุด
โหมดอะแดปเตอร์ไม่ซับซ้อนอย่างที่คุณคิดดังนั้นขอยกตัวอย่างที่ง่ายที่สุดให้คุณ
ไคลเอนต์เรียกใช้วิธีการคำนวณเพิ่มเติม:
var result = เพิ่ม (1,2);
อย่างไรก็ตามเราไม่ได้ให้วิธีการเพิ่มและให้วิธีการรวมที่มีฟังก์ชั่นที่คล้ายกันเดียวกัน:
ฟังก์ชั่นผลรวม (v1, v2) {return v1 + v2;}เพื่อหลีกเลี่ยงการแก้ไขไคลเอนต์และเซิร์ฟเวอร์เราเพิ่มฟังก์ชั่น wrapper:
ฟังก์ชั่นเพิ่ม (v1, v2) {reutrn sum (v1, v2);}นี่เป็นโหมดอะแดปเตอร์ที่ง่ายที่สุดเราเพิ่มวิธีการห่อหุ้มระหว่างอินเทอร์เฟซที่เข้ากันไม่ได้สองตัวและใช้วิธีนี้เพื่อเชื่อมต่อทั้งสองเพื่อให้พวกเขาทำงานร่วมกัน
2. แอปพลิเคชันที่ใช้งานได้จริง
ด้วยการพัฒนาเฟรมเวิร์กส่วนหน้านักพัฒนาจำนวนมากขึ้นเรื่อย ๆ ได้เริ่มใช้กรอบ MVVM เพื่อการพัฒนาเพียงต้องการจัดการข้อมูลโดยไม่มีองค์ประกอบ DOM และ jQuery มีผลน้อยลง หลายโครงการยังคงอ้างถึงคลาสเครื่องมือไลบรารี jQuery เพราะเราจำเป็นต้องใช้ AJAX ที่จัดทำโดย JQuery เพื่อขอข้อมูลไปยังเซิร์ฟเวอร์ หากบทบาทของ JQuery ในโครงการใช้เป็นห้องสมุดเครื่องมือ AJAX เท่านั้นมันรู้สึกเหมือนเป็นเหมือนการฆ่าไก่และทำให้เสียทรัพยากร ในเวลานี้เราสามารถห่อหุ้มห้องสมุด Ajax ของเราเองได้อย่างสมบูรณ์
สมมติว่า AJAX ที่เราห่อหุ้มใช้ผ่านฟังก์ชั่น:
ajax ({url: '/getData', พิมพ์: 'โพสต์', ข้อมูลประเภท: 'json', ข้อมูล: {id: "123"}}). เสร็จแล้ว (ฟังก์ชั่น () {})ยกเว้นความแตกต่างระหว่างการเรียกอินเทอร์เฟซ Ajax และ $ .ajax ของ jQuery ส่วนอื่น ๆ ก็เหมือนกันทุกประการ
ต้องมีหลายสถานที่ในโครงการที่ขออาแจ็กซ์ เมื่อเราแทนที่ jQuery เราไม่สามารถแก้ไข $ .ajax ทีละคนได้ เราควรทำอย่างไร? ในเวลานี้เราสามารถเพิ่มอะแดปเตอร์:
var $ = {ajax: function (ตัวเลือก) {return ajax (ตัวเลือก); -สิ่งนี้จะเข้ากันได้กับรหัสเก่าและอินเทอร์เฟซใหม่หลีกเลี่ยงการปรับเปลี่ยนรหัสที่มีอยู่
สรุป
หลักการของโหมดอะแดปเตอร์นั้นง่ายมากซึ่งคือการเพิ่มคลาส wrapper ใหม่เพื่อห่ออินเทอร์เฟซใหม่เพื่อปรับให้เข้ากับการโทรของรหัสเก่าและหลีกเลี่ยงการแก้ไขอินเทอร์เฟซและโทรรหัส
สถานการณ์ที่ใช้งานได้: มีรหัสหลายรายการเรียกอินเทอร์เฟซเก่า เพื่อหลีกเลี่ยงการปรับเปลี่ยนรหัสเก่าและแทนที่อินเทอร์เฟซใหม่สถานการณ์แอปพลิเคชันจะไม่ส่งผลกระทบต่อวิธีการใช้งานที่มีอยู่
1. โอกาสที่เกี่ยวข้องสำหรับโหมดอะแดปเตอร์:
อะแดปเตอร์เหมาะสำหรับสถานการณ์ที่อินเทอร์เฟซที่ระบบลูกค้าคาดหวังนั้นไม่เข้ากันกับที่ได้รับจาก API ที่มีอยู่ ทั้งสองวิธีที่ปรับให้เข้ากับอะแดปเตอร์ควรทำงานที่คล้ายกันมิฉะนั้นปัญหาจะไม่ได้รับการแก้ไข เช่นเดียวกับองค์ประกอบของสะพานและองค์ประกอบลักษณะที่ปรากฏโดยการสร้างอะแดปเตอร์นามธรรมสามารถแยกได้จากการใช้งานของพวกเขาเพื่อให้ทั้งสองสามารถเปลี่ยนแปลงได้อย่างอิสระ
2. ประโยชน์โหมดอะแดปเตอร์:
ห่ออินเตอร์เฟสของคลาสที่มีอยู่ด้วยอินเทอร์เฟซใหม่เพื่อให้โปรแกรมไคลเอนต์สามารถใช้คลาสนี้ที่ไม่ได้รับการปรับแต่งโดยไม่ต้องผ่าตัดที่สำคัญ
3. ข้อเสียของโหมด Orchestrator:
บางคนคิดว่าอะแดปเตอร์เป็นค่าใช้จ่ายที่ไม่จำเป็นซึ่งสามารถหลีกเลี่ยงได้ทั้งหมดโดยการเขียนรหัสที่มีอยู่ใหม่ นอกจากนี้โหมดอะแดปเตอร์จะแนะนำชุดเครื่องมือใหม่ที่ต้องรองรับ หาก API ที่มีอยู่ยังไม่ได้รูปร่างหรืออินเทอร์เฟซใหม่ยังไม่ได้รูปร่างอะแดปเตอร์อาจไม่ทำงานเสมอไป
ข้อดีของมันมีแนวโน้มที่จะโดดเด่นกว่าข้อเสียเมื่อมันเกี่ยวข้องกับระบบขนาดใหญ่และกรอบมรดก