อัปเดตล่าสุด: 31/10/2558

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

ฉันควรใช้อะแดปเตอร์เมื่อใด

เมื่อคุณต้องการใช้คลาสที่มีอยู่ แต่อินเทอร์เฟซไม่ตรงกับความต้องการของคุณ

เมื่อคุณต้องการใช้คลาสที่มีอยู่ร่วมกับคลาสอื่นที่มีอินเทอร์เฟซเข้ากันไม่ได้

คำจำกัดความอย่างเป็นทางการของรูปแบบใน UML มีดังนี้:

คำอธิบายอย่างเป็นทางการของอ็อบเจ็กต์อะแดปเตอร์ใน C# มีลักษณะดังนี้:

Class Client ( public void Request(Target target) ( target.Request(); ) ) // class ที่ต้องดัดแปลงคลาสอื่น class Target ( public virtual void Request() () ) // Adapter class Adapter: Target ( Adaptee ส่วนตัว = Adaptee ใหม่ (); แทนที่สาธารณะ void Request () ( adaptee.SpecificRequest (); ) ) // Adaptee คลาสคลาส Adaptee ( public void specificRequest () () )

ผู้เข้าร่วม

เป้าหมาย: หมายถึงวัตถุที่ลูกค้าใช้

ลูกค้า: ใช้วัตถุเป้าหมายเพื่อดำเนินงาน

Adaptee: แสดงถึงคลาสที่ปรับเปลี่ยนได้ที่เราต้องการให้ไคลเอนต์ใช้แทนวัตถุเป้าหมาย

อะแดปเตอร์: ตัวอะแดปเตอร์เอง ซึ่งช่วยให้คุณทำงานกับออบเจ็กต์ Adaptee ได้เช่นเดียวกับออบเจ็กต์ Target

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

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

โปรแกรมคลาส ( static void Main(args สตริง) ( // traveler Driver driver = new Driver(); // car Auto auto = new Auto(); // ไปเที่ยวกัน driver.Travel(auto); // sands พบกันเราต้องใช้อูฐ Camel = new Camel(); // ใช้อะแดปเตอร์ ITransport CamelToTransport = new CamelToTransportAdapter(camel); // ดำเนินการต่อเส้นทางผ่านไดรเวอร์ Sands Deserts ( void Drive(); ) // คลาสรถยนต์ คลาส Auto: ITransport ( public void Drive() ( Console.WriteLine("The car is running along the road"); ) ) class Driver ( public void Travel(ITransport Transport) ( การขนส่ง .Drive() ; ) ) // ส่วนต่อประสานกับสัตว์ IAnimal ( void Move(); ) // คลาสอูฐ อูฐ: IAnimal ( public void Move() ( Console.WriteLine("อูฐเดินไปตามหาดทราย"); ) ) // อะแดปเตอร์จาก Camel เป็นคลาส ITransport CamelToTransportAdapter: ITransport ( Camel Camel; CamelToTransportAdapter สาธารณะ (Camel c) ( อูฐ = c;

) โมฆะสาธารณะ Drive() ( Camel.Move(); ) )

และคอนโซลจะส่งออก:

มีรถยนต์แล่นไปตามถนน มีอูฐเดินไปตามผืนทราย

บางคนอาจพบว่าปัญหาในการใช้อะแดปเตอร์เป็นเรื่องที่ลึกซึ้ง โดยเฉพาะในกรณีนี้ เนื่องจากเราสามารถใช้อินเทอร์เฟซ ITransport กับคลาส Camel และใช้เมธอด Drive() ของมันได้ อย่างไรก็ตาม ในกรณีนี้ อาจมีความซ้ำซ้อนของฟังก์ชันการทำงาน: อินเทอร์เฟซ IAnimal มีเมธอด Move() ซึ่งการใช้งานในคลาส Camel อาจคล้ายกับการใช้งานเมธอด Drive() จากอินเทอร์เฟซ ITransport นอกจากนี้ มักเกิดขึ้นที่ชั้นเรียนได้รับการออกแบบโดยบุคคลอื่น และเราไม่มีอิทธิพลต่อชั้นเรียนเหล่านั้น เราแค่ใช้มัน ด้วยเหตุนี้ อะแดปเตอร์จึงค่อนข้างแพร่หลายใน .NET โดยเฉพาะอย่างยิ่ง คลาสในตัวจำนวนมากที่ใช้ในการเชื่อมต่อกับระบบฐานข้อมูลต่างๆ จะใช้รูปแบบอะแด็ปเตอร์ (ตัวอย่างเช่น คลาส System.Data.SqlClient.SqlDataAdapter)

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

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

หลักการทำงาน

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

ตัวอย่าง

บทสรุป

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

ในบทเรียนที่แล้ว เราได้ดูความเป็นไปได้ของรูปแบบการออกแบบ Façade ซึ่งคุณสามารถสร้างโค้ดของโปรเจ็กต์ขนาดใหญ่ขึ้นมาใหม่ได้

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

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

งาน

ในตัวอย่างข้างต้น เราใช้คลาส Twitter เพื่อทำให้ขั้นตอนการเผยแพร่ข้อความง่ายขึ้น ต่อไป เราสร้างวัตถุเพื่อเรียก Twitter API และเผยแพร่ข้อความ ลองนึกภาพโค้ดนี้ถูกใช้ในหลายที่ โปรดทราบว่าในการเผยแพร่ข้อความ เราใช้วิธี $twitter->send("Posting on Twitter");

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

สารละลาย

เพื่อเป็นการแก้ปัญหา เราสามารถใช้รูปแบบการออกแบบอะแดปเตอร์ได้

อะแดปเตอร์คือรูปแบบการออกแบบโครงสร้างที่ออกแบบมาเพื่อจัดระเบียบการใช้ฟังก์ชันของออบเจ็กต์ที่ไม่สามารถแก้ไขได้ผ่านอินเทอร์เฟซที่สร้างขึ้นเป็นพิเศษ

ก่อนอื่น เราต้องสร้างอินเทอร์เฟซขึ้นมาก่อน การเปลี่ยนรหัสของไลบรารีบุคคลที่สามนั้นไม่สมเหตุสมผลเพราะ... เนื้อหาอาจเปลี่ยนแปลงได้ตลอดเวลา

มาดูโค้ดบางส่วนที่เขียนโดยใช้รูปแบบการออกแบบอะแดปเตอร์:

// การใช้งานคลาส Twitter คลาส Twitter ( public function __construct() ( // Your Code here // ) public function send($msg) ( // Posting to Twitter // echo $msg; ) ) // Simple interface for อะแดปเตอร์แต่ละตัว ซึ่งจะถูกสร้างขึ้น อินเทอร์เฟซ socialAdapter ( public function send($msg); ) คลาส twitterAdapter ใช้งาน socialAdapter ( private $twitter; public function __construct(Twitter $twitter) ( $this->twitter = $twitter; ) public function send ($msg ) ( $นี่->twitter->ส่ง($msg); ) )

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

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

ตอนนี้เรามากำหนดวิธีการใช้เมธอดของคลาสดั้งเดิม:

// รหัสลูกค้า $twitter = twitterAdapter ใหม่ (Twitter ใหม่ ()); $twitter->send("กำลังโพสต์ไปที่ Twitter");

ทีนี้ลองจินตนาการว่า Twitter เปลี่ยนชื่อของวิธีการจาก send เป็น sendTweet ในกรณีนี้ เราจำเป็นต้องเปลี่ยน twitterAdapter เท่านั้น ดูรหัสอะแดปเตอร์ที่แก้ไข

คลาส twitterAdapter ใช้งาน socialAdapter ( $twitter ส่วนตัว; ฟังก์ชั่นสาธารณะ __construct(Twitter $twitter) ( $this->twitter = $twitter; ) ฟังก์ชั่นสาธารณะ send($msg) ( $this->twitter->sendTweet($msg); ) )

การเปลี่ยนแปลงเพียงครั้งเดียว เราก็กลับมาสู่เส้นทางเดิมอีกครั้ง

การเพิ่มอะแดปเตอร์ใหม่

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

แทนที่จะใช้คลาส Facebook โดยตรง มาสร้างอะแดปเตอร์ใหม่กันดีกว่า

คลาส Facebook ( ฟังก์ชั่นสาธารณะ __construct() ( // รหัสของคุณ // ) ฟังก์ชั่นสาธารณะ updateStatus($msg) ( // โพสต์บน Facebook // echo $msg; ) ) // คลาสอะแดปเตอร์ของ Facebook facebookAdapter ใช้งาน socialAdapter ( ส่วนตัว $facebook; ฟังก์ชั่นสาธารณะ __construct(Facebook $facebook) ( $this->facebook = $facebook; ) ฟังก์ชั่นสาธารณะ ส่ง($msg) ( $this->facebook->updateStatus($msg); ) ) // รหัสลูกค้า $facebook = ใหม่ facebookAdapter(เฟสบุ๊คใหม่()); $facebook->send("กำลังโพสต์ไปที่ Facebook");

อย่างที่คุณเห็นหลักการก็เหมือนกัน คุณกำหนดคลาส wrapper ที่คุณส่งผ่านอ็อบเจ็กต์คลาสดั้งเดิม เมื่อเปลี่ยน API คุณจะต้องเปลี่ยนโค้ดในที่เดียวเท่านั้น

บทสรุป

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

ฉันได้พยายามอย่างเต็มที่ที่จะแสดงตัวอย่างพื้นฐานแต่มีประโยชน์ของการใช้รูปแบบการออกแบบอะแดปเตอร์

อะแดปเตอร์ (รูปแบบการออกแบบ)/ตัวอย่างโค้ด- บทความหลัก: อะแดปเตอร์ (รูปแบบการออกแบบ) ตัวอย่างของการนำรูปแบบไปใช้ใน C# โดยใช้ระบบ; อะแดปเตอร์เนมสเปซ (คลาส MainApp ( static void Main() ( ... Wikipedia

รูปแบบพร็อกซี (รูปแบบการออกแบบ)

รูปแบบการออกแบบ- คำนี้มีความหมายอื่น ดูที่ Pattern ในการพัฒนาซอฟต์แวร์ รูปแบบการออกแบบหรือรูปแบบการออกแบบคือการออกแบบทางสถาปัตยกรรมที่ทำซ้ำได้ซึ่งแสดงถึงแนวทางแก้ไขปัญหา... ... Wikipedia

อินเทอร์เฟซ (รูปแบบการออกแบบ)- รูปแบบการออกแบบอินเทอร์เฟซที่อธิบายไว้ในรูปแบบการออกแบบ ไม่ใช่ ในวิทยาการคอมพิวเตอร์ รูปแบบอินเทอร์เฟซไม่ใช่รูปแบบพิเศษในบรรดารูปแบบการออกแบบ เป็นวิธีการทั่วไปในการจัดโครงสร้างโปรแกรมคอมพิวเตอร์เพื่อ... วิกิพีเดีย

รอง (แบบออกแบบ)- รูปแบบหนังสือมอบฉันทะ (รอง) รูปแบบการออกแบบ จัดเตรียมอ็อบเจ็กต์ควบคุมการเข้าถึง สกัดกั้นการเรียกทั้งหมดไปยังอ็อบเจ็กต์นั้น สารบัญ 1 เป้าหมาย 1.1 ปัญหา 1.2 แนวทางแก้ไข 2 ข้อดี 3 ... Wikipedia

ผู้พิทักษ์ (รูปแบบการออกแบบ)- รูปแบบการออกแบบ Guardian Memento Type: พฤติกรรมที่อธิบายไว้ในรูปแบบการออกแบบ ใช่ Guardian (หรือที่เรียกว่า Memento, Token, Token) เป็นรูปแบบการออกแบบเชิงพฤติกรรม ช่วยให้คุณแก้ไขได้โดยไม่ทำลายการห่อหุ้ม... Wikipedia

ตัววนซ้ำ (รูปแบบการออกแบบ)- Design Pattern Iterator Iterator Type: behavioral อธิบายไว้ในรูปแบบการออกแบบ ใช่ Iterator Pattern (หรือที่เรียกว่า Cursor) รูปแบบการออกแบบที่อ้างถึงรูปแบบพฤติกรรม เป็นวัตถุที่ช่วยให้คุณได้รับ ... Wikipedia

ล่าม (รูปแบบการออกแบบ)- รูปแบบการออกแบบ ประเภทล่าม: เชิงพฤติกรรม วัตถุประสงค์: แก้ปัญหาที่เกิดขึ้นบ่อยครั้งและมีแนวโน้มที่จะเปลี่ยนแปลง อธิบายไว้ในรูปแบบการออกแบบ ใช่ รูปแบบล่าม (ภาษาอังกฤษ ... Wikipedia

Linker (รูปแบบการออกแบบ)- รูปแบบการออกแบบ Composite Type: โครงสร้างอธิบายไว้ใน Design Patterns ใช่ Composite pattern เป็นรูปแบบการออกแบบ หมายถึง รูปแบบโครงสร้าง รวมวัตถุ ... Wikipedia

รัฐ (รูปแบบการออกแบบ)- รูปแบบการออกแบบของรัฐ ประเภท: เชิงพฤติกรรม อธิบายไว้ในรูปแบบการออกแบบ ใช่ สถานะคือรูปแบบการออกแบบ มันถูกใช้ในกรณีที่วัตถุ ... Wikipedia ในระหว่างการทำงานของโปรแกรม

กลับมาพิจารณารูปแบบการออกแบบโครงสร้างกันอีกครั้ง คราวนี้เราจะมาดูรูปแบบการออกแบบที่เรียกว่า อะแดปเตอร์(เรียกอีกอย่างว่า Wrapper ร่วมกับลวดลาย Facade)

ในบทความนี้เราจะพูดถึงสิ่งต่อไปนี้:

ดังนั้น รูปแบบอะแดปเตอร์จึงถูกนำมาใช้เพื่อให้ออบเจ็กต์ที่มีอินเทอร์เฟซเดียว (สัญญา) สามารถทำงานได้ในที่ที่จำเป็นต้องใช้ออบเจ็กต์ที่มีอินเทอร์เฟซที่แตกต่างกันโดยสิ้นเชิง อะแด็ปเตอร์มีสองประเภท - Class Adapter และ Object Adapter

ก่อนอื่น เราจะดูแต่ละประเภทเหล่านี้ จากนั้นฉันจะอธิบายความแตกต่างระหว่างกระดาษห่อทั้งสองแบบ - อะแดปเตอร์และส่วนหน้า

อะแดปเตอร์วัตถุ

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

ในกรณีที่ง่ายที่สุด การใช้งาน ObjectAdapter จะเป็นดังนี้:

ObjectAdapter ระดับสาธารณะใช้ TargetInterface (อะแดปเตอร์ Adaptee ส่วนตัว; โมฆะสาธารณะ targetMethod() ( adaptee.method() ) )

ข้อดีของแนวทางนี้คือเราแยกอินเทอร์เฟซไคลเอนต์ออกจากอินเทอร์เฟซที่ปรับเปลี่ยนได้อย่างสมบูรณ์

อะแดปเตอร์คลาส

ในกรณีของ Class Adapter จะมีการสืบทอดหลายรายการเพื่อให้บรรลุเป้าหมายของเรา ClassAdapter ของเราสืบทอดมาจากอินเทอร์เฟซไคลเอ็นต์และจากอินเทอร์เฟซที่ปรับเปลี่ยนได้ เนื่องจากไม่มีการสืบทอดหลายรายการใน Java มีเพียงบรรพบุรุษเดียวเท่านั้นที่สามารถเป็นคลาสนามธรรม/คอนกรีตได้ . บรรพบุรุษที่สองจะเป็นอินเทอร์เฟซซึ่งไม่สะดวกเสมอไป

แผนภาพชั้นเรียน:

และนี่คือการใช้งานคลาส ClassAdapter เล็กน้อย:

ClassAdapter ระดับสาธารณะขยาย Adaptee ใช้ TargetInterface ( โมฆะสาธารณะ targetMethod() ( method(); ) )

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

Class Adapter ถือเป็นโซลูชันที่ง่ายกว่าเมื่อไม่จำเป็นต้องแยกไคลเอ็นต์และอินเทอร์เฟซที่ปรับเปลี่ยนได้อย่างเคร่งครัด

ความแตกต่างระหว่างอะแดปเตอร์และ Facade

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

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

ตัวอย่างการใช้ Adapter ใน JDK

คุณยังสามารถค้นหาตัวอย่างการใช้อะแดปเตอร์ได้ในไลบรารีมาตรฐาน กรณีการใช้งานที่ได้รับความนิยมมากที่สุดน่าจะเป็น java.io.InputStreamReader และ OutputStreamWriter

ตัวสร้าง InputStreamReader ใช้ InputStream เป็นอินพุต และเป็นผลให้ปรับกระแสข้อมูลลงใน Reader

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