แทนที่การอ้างอิงโดยตรงด้วยการส่งข้อความ
บางครั้งโมดูลจำเป็นต้องแจ้งให้ผู้อื่นทราบว่ามีเหตุการณ์/การเปลี่ยนแปลงบางอย่างเกิดขึ้น และไม่สำคัญว่าจะเกิดอะไรขึ้นกับข้อมูลนี้ในภายหลัง
ในกรณีนี้โมดูลไม่จำเป็นต้อง "รู้จักกัน" เลยนั่นคือมีลิงก์โดยตรงและโต้ตอบโดยตรง แต่เพียงแค่แลกเปลี่ยนข้อความ (ข้อความ) หรือเหตุการณ์ (เหตุการณ์) ก็เพียงพอแล้ว
บางครั้งดูเหมือนว่าการสื่อสารของโมดูลผ่านการส่งข้อความนั้นอ่อนแอกว่าการพึ่งพาโดยตรง เนื่องจากเมธอดไม่ได้ถูกเรียกใช้ จึงไม่มีข้อมูลเกี่ยวกับคลาส แต่นี่ไม่ใช่อะไรมากไปกว่าภาพลวงตา
แทนที่จะเป็นชื่อเมธอด ตรรกะจะเริ่มเชื่อมโยงกับประเภทข้อความ พารามิเตอร์ และข้อมูลที่ส่ง การเชื่อมต่อของโมดูลดังกล่าวติดขัด
มันเคยเป็นแบบ: เราเรียกเมธอด - มีการเชื่อมต่อ เราไม่เรียกเมธอด - ไม่มีการเชื่อมต่อ ลองจินตนาการว่าโมดูล A เริ่มส่งข้อมูลที่แตกต่างกันเล็กน้อยในข้อความ และในเวลาเดียวกัน โมดูลทั้งหมดที่ขึ้นอยู่กับข้อความเหล่านี้จะทำงานไม่ถูกต้อง
สมมติว่าก่อนหน้านี้เมื่อเพิ่มผู้ใช้ใหม่ โมดูลการอนุญาตส่งข้อความUSER_ADDED และหลังจากการอัพเดต มันเริ่มส่งข้อความนี้เมื่อพยายามลงทะเบียนและระบุเพิ่มเติมว่าการลงทะเบียนสำเร็จหรือไม่ในพารามิเตอร์
ดังนั้นจึงเป็นสิ่งสำคัญมากที่จะต้องใช้กลไกข้อความอย่างมีประสิทธิภาพ มีเทมเพลตที่หลากหลายสำหรับสิ่งนี้
ผู้สังเกตการณ์ ใช้ในกรณีของการพึ่งพาแบบหนึ่งต่อกลุ่มเมื่อหลายโมดูลขึ้นอยู่กับสถานะของโมดูลเดียว - โมดูลหลัก มันใช้กลไกการส่งจดหมาย ซึ่งหมายความว่าโมดูลหลักเพียงแค่ส่งข้อความเดียวกันไปยังผู้สมัครสมาชิกทั้งหมด และโมดูลที่สนใจในข้อมูลนี้จะใช้อินเทอร์เฟซ "สมาชิก" และสมัครรับรายชื่อผู้รับจดหมาย
วิธีการนี้ใช้กันอย่างแพร่หลายในระบบที่มีอินเทอร์เฟซผู้ใช้ ช่วยให้แกนหลักของแอปพลิเคชัน (แบบจำลอง) ยังคงเป็นอิสระในขณะที่แจ้งอินเทอร์เฟซที่เกี่ยวข้องว่ามีบางอย่างเปลี่ยนแปลงและจำเป็นต้องอัปเดต
ที่นี่ รูปแบบข้อความเป็นมาตรฐานในระดับระบบปฏิบัติการ ซึ่งนักพัฒนาซอฟต์แวร์ต้องดูแลความเข้ากันได้ย้อนหลังและเอกสารประกอบที่ดี
องค์กรของการโต้ตอบผ่านการกระจายข้อความมี "โบนัส" เพิ่มเติม - การมีอยู่ของ "สมาชิก" ที่เป็นทางเลือกเพื่อ "เผยแพร่" (นั่นคือส่งออก) ข้อความ ระบบที่ออกแบบมาอย่างดีเช่นนี้ทำให้สามารถเพิ่ม/ลบโมดูลได้ตลอดเวลา
รถเมล์
คุณสามารถจัดระเบียบการแลกเปลี่ยนข้อความและใช้รูปแบบ คนกลางสำหรับสิ่งนี้ด้วยวิธีอื่น
ใช้เมื่อมีการพึ่งพาแบบกลุ่มต่อกลุ่มระหว่างโมดูล คนกลางทำหน้าที่เป็นตัวกลางในการสื่อสารระหว่างโมดูล ทำหน้าที่เป็นศูนย์กลางการสื่อสาร และขจัดความจำเป็นที่โมดูลจะต้องอ้างถึงซึ่งกันและกันอย่างชัดเจน
เป็นผลให้การโต้ตอบของโมดูลซึ่งกันและกัน (“ทั้งหมดกับทั้งหมด”) ถูกแทนที่ด้วยการโต้ตอบของโมดูลกับคนกลางเท่านั้น (“หนึ่งเดียวกับทั้งหมด”) มีการกล่าวถึงคนกลางเพื่อสรุปปฏิสัมพันธ์ระหว่างโมดูลต่างๆ
นี่คือสิ่งที่เรียกว่าตัวกลางอัจฉริยะ ที่นั่นนักพัฒนาส่วนใหญ่มักจะเริ่มเพิ่มไม้ค้ำซึ่งมีอิทธิพลต่อพฤติกรรมของแต่ละโมดูลโดยการเปิด / ปิดการรับข้อความบางอย่าง
ตัวอย่างในชีวิตจริงโดยทั่วไปคือการควบคุมการจราจรในสนามบิน ข้อความทั้งหมดจากเครื่องบินไปที่หอควบคุมของผู้ควบคุมแทนที่จะส่งโดยตรงระหว่างเครื่องบิน และผู้ควบคุมตัดสินใจอยู่แล้วว่าเครื่องบินลำใดสามารถขึ้นหรือลงได้ และส่งข้อความไปยังเครื่องบินด้วย
สำคัญ! โมดูลสามารถส่งข้อความถึงกันไม่เพียง แต่ข้อความธรรมดาเท่านั้น แต่ยังรวมถึงวัตถุคำสั่งด้วย การโต้ตอบดัง กล่าวอธิบายโดยเทมเพลต คำสั่ง บรรทัดล่างคือการสรุปคำขอเพื่อดำเนินการเฉพาะเป็นวัตถุแยกต่างหาก
อันที่จริงแล้ว อ็อบเจ็กต์นี้มี เมธอด execute()เดียว ซึ่งอนุญาตให้คุณส่งการดำเนินการนี้ไปยังโมดูลอื่นเพื่อดำเนินการเป็นพารามิเตอร์ และโดยทั่วไปดำเนินการกับออบเจ็กต์คำสั่งที่สามารถดำเนินการกับออบเจ็กต์ทั่วไป
กฎของดีมีเตอร์
กฎของ Demeterห้ามการใช้การพึ่งพาโดยปริยาย: "วัตถุ A ต้องไม่สามารถเข้าถึงวัตถุ C ได้โดยตรง ถ้าวัตถุ A สามารถเข้าถึงวัตถุ B และวัตถุ B สามารถเข้าถึงวัตถุ C"
ซึ่งหมายความว่าการพึ่งพาทั้งหมดในโค้ดต้อง "ชัดเจน" - คลาส / โมดูลสามารถใช้ "การพึ่งพา" ในการทำงานเท่านั้น และไม่ควรส่งต่อไปยังผู้อื่น ตัวอย่างที่ดีคือสถาปัตยกรรมสามชั้น เลเยอร์อินเทอร์เฟซควรทำงานร่วมกับเลเยอร์ลอจิก แต่ไม่ควรโต้ตอบโดยตรงกับเลเยอร์ฐานข้อมูล
โดยสังเขป หลักการนี้มีการกำหนดในลักษณะนี้เช่นกัน: "โต้ตอบกับเพื่อนที่ใกล้ชิดเท่านั้น ไม่ใช่กับเพื่อนของเพื่อน" สิ่งนี้ทำให้โค้ดมีความสอดคล้องกันน้อยลง รวมถึงการมองเห็นและความโปร่งใสของการออกแบบที่มากขึ้น
กฎของดีมีเตอร์ใช้ "หลักการของความรู้ขั้นต่ำ" ที่กล่าวถึงแล้วซึ่งเป็นพื้นฐานของการมีเพศสัมพันธ์แบบหลวมและประกอบด้วยความจริงที่ว่าวัตถุ / โมดูลควรรู้รายละเอียดน้อยที่สุดเกี่ยวกับโครงสร้างและคุณสมบัติของวัตถุ / โมดูลอื่น ๆ และ โดยทั่วไปรวมถึงส่วนประกอบ ของตัว เอง
การเปรียบเทียบจากชีวิต: ถ้าคุณต้องการให้สุนัขวิ่ง มันโง่ที่จะสั่งอุ้งเท้า มันจะดีกว่าถ้าออกคำสั่งกับสุนัข และเธอจะจัดการกับอุ้งเท้าของเธอเอง
องค์ประกอบแทนการสืบทอด
นี่เป็นหัวข้อที่ใหญ่และน่าสนใจ และสมควรได้รับการบรรยายแยกต่างหากเป็นอย่างน้อย สำเนาจำนวนมากถูกทำลายในหัวข้อนี้บนอินเทอร์เน็ตจนกว่าจะถึงฉันทามติ - เราใช้การสืบทอดให้น้อยที่สุด, การเรียบเรียง - ให้สูงสุด
ประเด็นก็คือการสืบทอดให้การเชื่อมต่อระหว่างคลาสที่แข็งแกร่งที่สุด ดังนั้นควรหลีกเลี่ยง หัวข้อนี้ครอบคลุมอยู่ในบทความของ Herb Sutter เรื่อง " Prefer Composition Over Inheritance "
เมื่อคุณเริ่มเรียนรู้รูปแบบการออกแบบ คุณจะพบกับรูปแบบมากมายที่ควบคุมการสร้างวัตถุหรือโครงสร้างภายใน อย่างไรก็ตาม ฉันสามารถแนะนำในบริบทนี้ให้ใส่ใจกับ รูป แบบ ผู้ร่วมประชุม / ผู้ร่วมประชุมและ รูปแบบ ส่วนประกอบ ที่มาจากเกม
เราจะพูดถึงรูปแบบเพิ่มเติมในภายหลัง