ขอบคุณ "การวิเคราะห์รูปแบบการออกแบบซอร์สโค้ด Android และการปฏิบัติจริง" เขาฮงฮุ่ยดูแลผู้คน
โหมดอะแดปเตอร์มีประโยชน์อย่างมากในการพัฒนาของเรา สามารถตัดสินได้จากอะแดปเตอร์ที่สามารถมองเห็นได้ทุกที่ในรหัส จาก ListView ที่เก่าแก่ที่สุด, Gridview และ Recyclerview ล่าสุดเราทุกคนจำเป็นต้องใช้อะแดปเตอร์และปัญหาการเพิ่มประสิทธิภาพและสถานที่ที่มีความน่าจะเป็นสูงของข้อผิดพลาดที่เราพบในการพัฒนานั้นได้มาจากอะแดปเตอร์
อะแดปเตอร์จะหลอมรวมมังกรไฟที่เข้ากันไม่ได้สองตัวเข้าด้วยกันและใช้การเปลี่ยนแปลงเพื่อให้พวกเขาทำงานร่วมกันได้ ตัวอย่างเช่นมักพบว่าคุณต้องการโต้ตอบระหว่างสองประเภทที่ไม่เกี่ยวข้อง ทางออกแรกคือการปรับเปลี่ยนอินเทอร์เฟซของแต่ละคลาส อย่างไรก็ตามหากไม่มีซอร์สโค้ดหรือเราไม่เต็มใจที่จะแก้ไขอินเทอร์เฟซที่เกี่ยวข้องสำหรับแอปพลิเคชันในกรณีนี้เรามักจะใช้อะแดปเตอร์ซึ่งจะเข้ากันได้ทั้งสองอินเตอร์เฟสและตอบสนองความต้องการโดยไม่ต้องแก้ไขรหัสดั้งเดิม
สมมติว่ามีระบบซอฟต์แวร์อยู่แล้วและคุณต้องการให้ใช้กับไลบรารีคลาสของผู้ผลิตรายใหม่ แต่อินเทอร์เฟซที่ออกแบบโดยผู้ผลิตรายใหม่นี้ไม่ได้ใช้สำหรับอินเทอร์เฟซของผู้ผลิตเก่า:
คุณควรทำอย่างไรถ้าคุณไม่ต้องการเปลี่ยนรหัสที่มีอยู่และแก้ปัญหานี้ (และคุณไม่สามารถเปลี่ยนรหัสของผู้ผลิตได้) คุณสามารถเขียนคลาส (อะแดปเตอร์) ที่แปลงอินเทอร์เฟซผู้ขายใหม่เป็นอินเทอร์เฟซที่คุณคาดหวัง อะแดปเตอร์นี้ทำงานเหมือนตัวกลางซึ่งแปลงคำขอที่ลูกค้าออกเป็นคำขอว่าคลาสผู้ขายสามารถเข้าใจได้
โหมดอะแดปเตอร์สามารถแบ่งออกเป็นสองประเภท:
อะแดปเตอร์วัตถุ: เต็มไปด้วยหลักการออกแบบ OO ที่ดี การใช้การรวมกันของวัตถุสามารถนำไปใช้กับอะแดปเตอร์เป็นอินเทอร์เฟซและคลาสย่อยทั้งหมด วิธีการอะแดปเตอร์ไม่สามารถเขียนใหม่ได้เนื่องจากไม่มีความสัมพันธ์ในการสืบทอด แต่ยังสามารถ "นำเสนอใหม่" วิธีการในอะแดปเตอร์ ลูกค้าและอะแดปเตอร์นั้นไม่เกี่ยวข้องอย่างสมบูรณ์และมีเพียงอะแดปเตอร์เท่านั้นที่มีการอ้างอิงถึงอะแดปเตอร์
อะแดปเตอร์คลาส: ใช้การสืบทอดเพื่อให้ได้งานของอะแดปเตอร์ เฉพาะอะแดปเตอร์เท่านั้นที่เป็นอินเทอร์เฟซและไม่สามารถใช้อินเทอร์เฟซ subclass ได้ เมื่อมีการสร้างอะแดปเตอร์คลาสจะมีความสัมพันธ์แบบคงที่กับอะแดปเตอร์ อะแดปเตอร์ทำหน้าที่เป็นคลาสพื้นฐานของอะแดปเตอร์ดังนั้นอะแดปเตอร์สามารถเขียนวิธีการใหม่ในอะแดปเตอร์ รหัสลูกค้าสามารถมองเห็นรหัสที่ประกาศในอะแดปเตอร์ รหัสลูกค้าสามารถมองเห็นรหัสที่ประกาศในอะแดปเตอร์
คำนิยาม:
รูปแบบอะแดปเตอร์แปลงอินเทอร์เฟซของคลาสหนึ่งเป็นอินเทอร์เฟซอื่นที่ลูกค้าคาดหวังดังนั้นสองคลาสที่ไม่สามารถทำงานร่วมกันได้เนื่องจากอินเทอร์เฟซไม่ตรงกันสามารถทำงานร่วมกันได้
ใช้สถานการณ์:
1. ระบบจำเป็นต้องใช้คลาสที่มีอยู่และอินเทอร์เฟซดังกล่าวไม่ตรงกับความต้องการของระบบนั่นคืออินเทอร์เฟซไม่เข้ากัน
2. ต้องการสร้างคลาสที่สามารถนำกลับมาใช้ใหม่เพื่อทำงานกับบางชั้นเรียนที่ไม่เกี่ยวข้องกันมากรวมถึงบางคลาสที่อาจนำมาใช้ในอนาคต
3. จำเป็นต้องใช้อินเทอร์เฟซเอาต์พุตแบบครบวงจรและประเภทของอินพุตปลายไม่สามารถคาดการณ์ได้
แผนภาพคลาส UML:
ดูอะแดปเตอร์ต่อไปนี้ก่อน:
คลาสอะแดปเตอร์ใช้การแปลงอินเทอร์เฟซโดยใช้อินเทอร์เฟซเป้าหมายและสืบทอดคลาส Adaptee ตัวอย่างเช่นอินเทอร์เฟซเป้าหมายต้องใช้ Operation2 แต่วัตถุ Adaptee มีเพียงหนึ่งการดำเนินการ 3 ดังนั้นจึงมีสถานการณ์ที่เข้ากันไม่ได้ ในเวลานี้ฟังก์ชั่น Operation2 จะถูกนำไปใช้ผ่านอะแดปเตอร์เพื่อแปลงการทำงานของ Adaptee 3 เป็น Operation2 ที่ต้องการโดยเป้าหมายเพื่อให้บรรลุความเข้ากันได้
เป้าหมาย: บทบาทเป้าหมายนั่นคืออินเทอร์เฟซที่คุณกำลังมองหา หมายเหตุ: เนื่องจากรูปแบบอะแดปเตอร์คลาสถูกกล่าวถึงที่นี่เป้าหมายจึงไม่สามารถเป็นคลาสได้
Adaptee: ต้องใช้อินเทอร์เฟซที่ดัดแปลงแล้ว
อะแดปเตอร์: บทบาทอะแดปเตอร์ยังเป็นแกนหลักของโหมดนี้ อะแดปเตอร์แปลงอินเทอร์เฟซต้นทางเป็นอินเทอร์เฟซเป้าหมาย บทบาทนี้ไม่สามารถเป็นอินเทอร์เฟซ แต่ต้องเป็นคลาสเฉพาะ
ตัวอย่างโหมดอะแดปเตอร์คลาส:
ใช้แรงดันไฟฟ้าแผ่นดินใหญ่คือ 220V และแรงดันโทรศัพท์มือถือเป็นตัวอย่าง 5V เป็นตัวอย่าง
/** * เป้าหมายคลาสแรงดันไฟฟ้าเป้าหมาย * @author Administrator * */แรงดันไฟฟ้าส่วนต่อประสานสาธารณะ {public int getVoltage ();} ชั้นเรียนสาธารณะ Chinavoltage ใช้แรงดันไฟฟ้า {@Override สาธารณะ int getVoltage () {// แรงดันไฟฟ้าทวีคูณคือ 220 กลับ 220; }} <ชื่อก่อน = "รหัส">/** * คลาสโทรศัพท์มือถือ, คลาสอะแดปเตอร์ Adaptee * @author Administrator * */คลาสสาธารณะ PhoneVoltage {/** * แรงดันโทรศัพท์มือถือคือ 5V * @return */สาธารณะ int getPhoneVoltage () {กลับ 5; }} <ชื่อก่อน = "รหัส">/** * ผู้ดูแลระบบอะแดปเตอร์ที่ชาร์จ * */เครื่องชาร์จระดับสาธารณะขยายการใช้งาน PhoneVoltage ใช้แรงดันไฟฟ้า {@Override สาธารณะ int getVoltage () {return getPhoneVoltage (); }} ไคลเอนต์คลาสสาธารณะ {โมฆะคงที่สาธารณะหลัก (สตริง [] args) {chinavoltage vol = ใหม่ chinavoltage (); System.out.println ("แรงดันไฟฟ้าแผ่นดินใหญ่คือ:" + vol.getVoltage ()); // แรงดันไฟฟ้าเมื่อเชื่อมต่อเครื่องชาร์จเข้ากับอักขระเครื่องชาร์จโทรศัพท์มือถือ = ใหม่ ChargerR (); System.out.println ("แรงดันไฟฟ้าที่แปลงผ่านเครื่องชาร์จ:" + character.getVoltage ()); - ผลการทำงาน:
แรงดันไฟฟ้าในจีนแผ่นดินใหญ่คือ: 220
แรงดันไฟฟ้าแปลงผ่านเครื่องชาร์จ: 5
มาดูไดอะแกรมคลาสอะแดปเตอร์วัตถุ:
ต่อไปนี้คือการแก้ไขคลาส ChargerR โดยใช้อะแดปเตอร์วัตถุ
<name pre = "code">/** * ผู้ดูแลระบบอะแดปเตอร์ที่ชาร์จ * */คลาสสาธารณะ Chargerr ใช้แรงดันไฟฟ้า {private phonevoltage phonev; Public Chargerr (PhoneVoltage Phonev) {this.phonev = phonev; } @Override สาธารณะ int getVoltage () {return phonev.getPhoneVoltage (); -วิธีการใช้งานอะแดปเตอร์วัตถุโดยตรงผ่านวัตถุที่จะปรับเป็นอะแดปเตอร์และใช้รูปแบบรวมเพื่อให้ได้ผลของความเข้ากันได้ของอินเตอร์เฟส สิ่งนี้มีความยืดหยุ่นมากกว่าวิธีอะแดปเตอร์คลาส ข้อได้เปรียบอีกประการหนึ่งคือวิธีการในวัตถุที่ดัดแปลงจะไม่ถูกเปิดเผย เนื่องจากอะแดปเตอร์คลาสสืบทอดวัตถุที่ดัดแปลงฟังก์ชั่นของคลาสวัตถุที่ปรับตัวจึงมีอยู่ในคลาสอะแดปเตอร์ซึ่งทำให้คลาสอะแดปเตอร์มีอินเทอร์เฟซแปลก ๆ ซึ่งมีประสิทธิภาพมากขึ้นสำหรับผู้ใช้ ดังนั้นโหมดอะแดปเตอร์วัตถุมีความยืดหยุ่นและใช้งานได้จริง
ไคลเอนต์ระดับสาธารณะ {โมฆะคงที่สาธารณะหลัก (สตริง [] args) {// chinavoltage vol = ใหม่ chinavoltage (); // system.out.println ("แรงดันไฟฟ้าแผ่นดินใหญ่คือ:" + vol.getVoltage (); // // แรงดันไฟฟ้า แปลงผ่านเครื่องชาร์จ: " + character.getVoltage ()); // ดัดแปลง phonevoltage phonev = new PhoneVoltage (); Chargerr Charger = ใหม่ Chargerr (Phonev); System.out.println ("แรงดันไฟฟ้าแปลงผ่านเครื่องชาร์จ:" + charger.getVoltage ()); } // ผลการดำเนินงาน: // แรงดันไฟฟ้าที่แปลงผ่านเครื่องชาร์จ: 5} สรุป:
การใช้งานแบบคลาสสิกของโมเดลอะแดปเตอร์คือการรวมอินเทอร์เฟซที่เข้ากันไม่ได้ครั้งแรกเพื่อให้สามารถร่วมมือกันได้ดี อย่างไรก็ตามในการพัฒนาจริงโมเดลอะแดปเตอร์ยังมีการใช้งานที่ยืดหยุ่น ตัวอย่างเช่นการเปลี่ยนแปลงการแยกใน ListView ทำให้สถาปัตยกรรม UI ทั้งหมดมีความยืดหยุ่นมากขึ้นและสามารถยอมรับการเปลี่ยนแปลง โมเดลอะแดปเตอร์ใช้กันอย่างแพร่หลายในการพัฒนา
ข้อได้เปรียบ:
ความสามารถในการนำกลับมาใช้ใหม่ได้ดีขึ้น: ระบบจำเป็นต้องใช้คลาสที่มีอยู่และอินเทอร์เฟซดังกล่าวไม่ตรงกับความต้องการของระบบ จากนั้นฟังก์ชั่นเหล่านี้สามารถนำกลับมาใช้ใหม่ได้ดีขึ้นผ่านโหมดอะแดปเตอร์
ความสามารถในการปรับขนาดที่ดีขึ้น: เมื่อใช้ฟังก์ชั่นอะแดปเตอร์คุณสามารถเรียกฟังก์ชั่นที่คุณพัฒนาขึ้นด้วยตัวเองเพื่อขยายฟังก์ชั่นของระบบตามธรรมชาติ
ข้อบกพร่อง:
การใช้อะแดปเตอร์มากเกินไปจะทำให้ระบบยุ่งและเข้าใจยากมาก ตัวอย่างเช่น Chang A อินเทอร์เฟซที่เรียกว่าจริง ๆ แล้วปรับให้เข้ากับการใช้งานของอินเตอร์เฟส B หากมีหลายกรณีในระบบนี้มากเกินไปมันก็เป็นไปได้ที่ภัยพิบัติ ดังนั้นหากไม่จำเป็นต้องใช้อะแดปเตอร์แทนการปรับเปลี่ยนระบบโดยตรง
ข้างต้นเป็นเนื้อหาทั้งหมดของบทความนี้ ฉันหวังว่ามันจะเป็นประโยชน์ต่อการเรียนรู้ของทุกคนและฉันหวังว่าทุกคนจะสนับสนุน wulin.com มากขึ้น