8.1 การสลายตัวคือทุกสิ่ง
เพื่อความชัดเจน รูปภาพจากบทความดีๆ เรื่อง "Decoupling of Object-Oriented Systems" ซึ่งแสดงประเด็นหลักที่จะกล่าวถึง
คุณยังคิดว่าการออกแบบสถาปัตยกรรมแอปพลิเคชันเป็นเรื่องง่ายหรือไม่?
8.2 อินเทอร์เฟซ การซ่อนการใช้งาน
หลักการสำคัญในการลดการเชื่อมต่อของระบบคือหลักการของ OOP และหลักการของ Encapsulation + Abstraction + Polymorphism ที่อยู่เบื้องหลัง
นั่นคือเหตุผล:
- โมดูลควรเป็น "กล่องดำ" สำหรับแต่ละโมดูล (การห่อหุ้ม ) ซึ่งหมายความว่าโมดูลหนึ่งไม่ควร "ปีน" เข้าไปในโมดูลอื่นและรู้อะไรเกี่ยวกับโครงสร้างภายในของมัน อ็อบเจ็กต์ในระบบย่อยหนึ่งไม่ควรเข้าถึงอ็อบเจ็กต์ในระบบย่อยอื่นโดยตรง
- โมดูล/ระบบย่อยควรโต้ตอบกันผ่านอินเทอร์เฟซเท่านั้น (นั่นคือabstractionsที่ไม่ขึ้นอยู่กับรายละเอียดการใช้งาน) ดังนั้น แต่ละโมดูลจะต้องมีส่วนต่อประสานหรือส่วนต่อประสานที่กำหนดไว้อย่างดีสำหรับการโต้ตอบกับโมดูลอื่น
หลักการของ "กล่องดำ" (การห่อหุ้ม) ช่วยให้เราสามารถพิจารณาโครงสร้างของแต่ละระบบย่อยโดยไม่ขึ้นกับระบบย่อยอื่นๆ โมดูลซึ่งเป็น "กล่องดำ" สามารถเปลี่ยนแปลงได้อย่างอิสระ ปัญหาสามารถเกิดขึ้นได้เฉพาะที่ทางแยกของโมดูลต่างๆ (หรือโมดูลและสภาพแวดล้อม)
และการโต้ตอบนี้จะต้องอธิบายในรูปแบบทั่วไป (นามธรรม) นั่นคือในรูปแบบของส่วนต่อประสาน ในกรณีนี้ โค้ดจะทำงานเหมือนกันกับการใช้งานใดๆ ที่สอดคล้องกับสัญญาอินเตอร์เฟส ความสามารถในการทำงานร่วมกับการใช้งานที่แตกต่างกัน (โมดูลหรือวัตถุ) ผ่านทางอินเทอร์เฟซแบบรวมที่เรียกว่า polymorphism
นั่นคือเหตุผลที่Servlet เป็นอินเตอร์เฟส : เว็บคอนเทนเนอร์ไม่รู้อะไรเลยเกี่ยวกับเซิร์ฟเล็ต เพราะสิ่งเหล่านี้คืออ็อบเจกต์บางอย่างที่ใช้อินเตอร์เฟส Servlet แค่นั้น Servlets ยังรู้เพียงเล็กน้อยเกี่ยวกับโครงสร้างของคอนเทนเนอร์ อินเตอร์เฟสของ Servlet คือสัญญา มาตรฐานนั้น การโต้ตอบขั้นต่ำที่จำเป็นในการทำให้เว็บแอปพลิเคชัน Java ครอบครองโลก
ความแตกต่างไม่ได้อยู่เหนือวิธีการอย่างที่บางครั้งเชื่อกันผิด แต่ก่อนอื่นความสามารถในการใช้แทนกันได้ของโมดูล / วัตถุที่มีอินเทอร์เฟซเดียวกันหรือ ในการใช้ความหลากหลาย กลไกการสืบทอดไม่จำเป็นเลย นี่เป็นสิ่งสำคัญที่ต้องเข้าใจ เพราะโดยทั่วไปแล้วควรหลีกเลี่ยงการรับมรดกเมื่อทำได้
ด้วยอินเทอร์เฟซและความหลากหลายทำให้สามารถแก้ไขและขยายโค้ดได้อย่างแม่นยำโดยไม่ต้องเปลี่ยนแปลงสิ่งที่เขียนไว้แล้ว (หลักการเปิด-ปิด)
ตราบใดที่มีการอธิบายการโต้ตอบของโมดูลเฉพาะในรูปแบบของอินเทอร์เฟซและไม่เชื่อมโยงกับการใช้งานเฉพาะ คุณมีโอกาสที่จะ "ไม่ลำบาก" สำหรับระบบอย่างแน่นอน แทนที่โมดูลหนึ่งด้วยโมดูลอื่นที่ใช้อินเทอร์เฟซเดียวกัน เช่นเดียวกับ เพิ่มอันใหม่และขยายฟังก์ชันการทำงาน
มันเหมือนกับในตัวสร้างเลโก้ - อินเทอร์เฟซสร้างมาตรฐานการโต้ตอบและทำหน้าที่เป็นตัวเชื่อมต่อชนิดหนึ่งที่สามารถเชื่อมต่อโมดูลใด ๆ ที่มีตัวเชื่อมต่อที่เหมาะสมได้
ความยืดหยุ่นของนักออกแบบนั้นรับประกันได้จากความจริงที่ว่าเราสามารถแทนที่โมดูลหรือชิ้นส่วนหนึ่งด้วยอีกโมดูลหนึ่งด้วยตัวเชื่อมต่อเดียวกัน (ด้วยอินเทอร์เฟซเดียวกัน) รวมถึงเพิ่มชิ้นส่วนใหม่ได้มากเท่าที่เราต้องการ (ในเวลาเดียวกัน ที่มีอยู่ ไม่มีการเปลี่ยนแปลงหรือดัดแปลงอะไหล่แต่อย่างใด)
อินเทอร์เฟซช่วยให้คุณสร้างระบบที่ง่ายขึ้น โดยพิจารณาจากระบบย่อยแต่ละระบบโดยรวมและละเว้นโครงสร้างภายใน พวกเขาอนุญาตให้โมดูลโต้ตอบและในขณะเดียวกันก็ไม่รู้อะไรเลยเกี่ยวกับโครงสร้างภายในของกันและกัน ดังนั้นจึงใช้หลักการของความรู้ขั้นต่ำอย่างเต็มที่ซึ่งเป็นพื้นฐานของการมีเพศสัมพันธ์แบบหลวม
ยิ่งมีการกำหนดอินเทอร์เฟซทั่วไป/นามธรรมมากขึ้น และข้อจำกัดที่กำหนดในการโต้ตอบน้อยลง ระบบก็ยิ่งมีความยืดหยุ่นมากขึ้นเท่านั้น จากที่นี่ หลักการของ SOLID อีกข้อหนึ่งตามมาจริง ๆ - หลักการแยกส่วนต่อ ประสาน ซึ่งตรงข้ามกับ "ส่วนต่อประสานแบบหนา"
เขากล่าวว่าอินเทอร์เฟซขนาดใหญ่เทอะทะควรแยกย่อยออกเป็นขนาดเล็กและเฉพาะเจาะจงมากขึ้น เพื่อให้ไคลเอ็นต์ของอินเทอร์เฟซขนาดเล็ก (ขึ้นอยู่กับโมดูล) รู้เฉพาะเกี่ยวกับวิธีการที่พวกเขาต้องใช้งานเท่านั้น
หลักการนี้มีการกำหนดดังนี้: "ไคลเอนต์ไม่ควรพึ่งพาวิธีการ (ระวังวิธีการ) ที่พวกเขาไม่ได้ใช้" หรือ "อินเทอร์เฟซเฉพาะจำนวนมากดีกว่าหนึ่งสากล"
ปรากฎว่ามีการเชื่อมต่อที่อ่อนแอก็ต่อเมื่อมีการอธิบายการโต้ตอบและการพึ่งพาของโมดูลด้วยความช่วยเหลือของอินเทอร์เฟซเท่านั้น นั่นคือ abstractions โดยไม่ต้องใช้ความรู้เกี่ยวกับโครงสร้างและโครงสร้างภายใน และอันที่จริง จึงมีการนำการห่อหุ้มมาใช้ นอกจากนี้ เรายังมีความสามารถในการขยาย/เปลี่ยนแปลงลักษณะการทำงานของระบบโดยการเพิ่มและการใช้งานที่แตกต่างกัน ซึ่งก็คือเนื่องจากความหลากหลาย ใช่ เรามาที่ OOP อีกครั้ง - Encapsulation, Abstraction, Polymorphism
8.3 Facade: ส่วนต่อประสานโมดูล
โปรแกรมเมอร์ที่มีประสบการณ์จะถามที่นี่: หากการออกแบบไม่ได้อยู่ในระดับของวัตถุที่ใช้อินเทอร์เฟซที่เกี่ยวข้องเอง แต่ในระดับของโมดูลการใช้อินเทอร์เฟซโมดูลคืออะไร
คำตอบ: พูดในภาษาของรูปแบบการออกแบบ วัตถุพิเศษสามารถรับผิดชอบในการใช้งานอินเทอร์เฟซโมดูล - Facade . หากคุณกำลังเรียกใช้เมธอดบนอ็อบเจ็กต์ที่มีส่วนต่อท้ายเกตเวย์ (เช่น MobileApiGateway) แสดงว่าเป็นไปได้มากว่าเป็นส่วนหน้า
ซุ้มคือออบเจกต์อินเทอร์เฟซที่สะสมชุดการดำเนินการระดับสูงสำหรับการทำงานกับระบบย่อยบางระบบ โดยซ่อนโครงสร้างภายในและความซับซ้อนที่แท้จริงไว้เบื้องหลัง ให้การป้องกันการเปลี่ยนแปลงในการใช้งานระบบย่อย ทำหน้าที่เป็นจุดเริ่มต้นเดียว - "คุณเตะส่วนหน้า และเขารู้ว่าใครต้องถูกเตะในระบบย่อยนี้เพื่อให้ได้สิ่งที่เขาต้องการ"
คุณเพิ่งได้รับการแนะนำให้รู้จักกับหนึ่งในรูปแบบการออกแบบที่สำคัญที่สุดที่ช่วยให้คุณสามารถใช้แนวคิดของอินเทอร์เฟซเมื่อออกแบบโมดูล และด้วยเหตุนี้จึงแยกโมดูลเหล่านั้นออก - "Facade"
นอกจากนี้ "Facade" ยังช่วยให้สามารถทำงานกับโมดูลในลักษณะเดียวกับวัตถุทั่วไปและใช้หลักการและเทคนิคที่มีประโยชน์ทั้งหมดซึ่งใช้ในการออกแบบคลาสเมื่อออกแบบโมดูล
หมายเหตุ : แม้ว่าโปรแกรมเมอร์ส่วนใหญ่จะเข้าใจถึงความสำคัญของอินเทอร์เฟซเมื่อออกแบบคลาส (วัตถุ) แต่ดูเหมือนว่าหลายคนจะค้นพบแนวคิดของการใช้อินเทอร์เฟซในระดับโมดูลเช่นกัน