มีอาการอะไรในรหัสฐานที่ระบุว่าจำเป็นต้องใช้วิธีการฟังเหตุการณ์?
สำหรับฉันแล้วดูเหมือนว่าเมื่อมีคลาสที่ต้องถูกเรียกโดยหลาย ๆ ตัวไม่ได้ถูกกำหนดในชุดการออกแบบของคลาสอื่นคุณต้องมีเฟรมเวิร์กการส่งสัญญาณบางอย่าง แต่ฉันอยากได้ยินสถานการณ์อื่น ๆ ที่จะมี ปรับปรุงโดยการเปลี่ยนเป็นโมเดลตามเหตุการณ์
คำตอบ:
เหตุการณ์ / ฟัง aproach พยายามหลีกเลี่ยงการแต่งงานกันอย่างแน่นหนาดังนั้นทุกรหัสกลิ่นที่ระบุว่าจะชี้ไปที่ appoach
จากนั้นฉันจะแนะนำอาการต่อไปนี้:
ตัวสร้างขนาดใหญ่เนื่องจากทุกวัตถุต้องรู้วัตถุอื่นทั้งหมดและไม่สามารถทำงานได้หากไม่มี อาจปลอมตัวเป็นจำนวนมากobj.set_dependecy(x)ทันทีหลังจากการโทรคอนสตรัค
การอ้างอิงแบบสองทิศทางเนื่องจากไม่มีเหตุการณ์ในภาษาที่จำเป็นการไหลของข้อมูลนั้นโดยทั่วไปแล้วจะเป็น 'push' (การเรียกเมธอด someones)
'ลำดับชั้นของความรู้' เป็นเรื่องยากที่จะตรวจสอบ นี่คือการพึ่งพาแบบสองทิศทางเพียงโฟกัสอีกอัน: ถ้ามี A, นั่นฟัง B, A รู้จัก B แต่ B ไม่เป็น A ดังนั้นจึงมี 'ลำดับขั้น': วัตถุบางอย่างไม่ทราบอะไรเลยบางคนรู้เรื่องอื่น เป็นต้นตัวอย่างเช่นเมื่อใช้ MVC แบบนี้: http://en.wikipedia.org/wiki/Model_View_Controllerแบบจำลองรู้เพียงตัวเองเท่านั้นมุมมองรู้ถึงแบบจำลองและผู้ควบคุมรู้ถึงมุมมองและแบบจำลอง
เมื่อคุณไม่สามารถหรือไม่ควรรู้สิ่งที่ควรตอบสนองต่อชุดของข้อความ / สัญญาณ / เหตุการณ์
บ่อยครั้งที่คุณต้องการให้ "โลก" รู้เกี่ยวกับบางสิ่งที่เกิดขึ้นในโมดูล (คลาสหรือระบบของคลาส) แต่คุณไม่ต้องการรบกวนสิ่งที่เรียกว่า
กลิ่นรหัสที่เกี่ยวข้องนั้นจะเฉพาะเจาะจงคือเมื่อคุณรู้สึกว่าคุณเริ่มผสมรหัสจากโมดูลอิสระหนึ่งทำในสิ่งที่คนอื่นควรตอบสนอง เมื่อคุณเห็นว่าคุณต้องเรียกรหัสจากโมดูล B ขึ้นอยู่กับสถานะ / เหตุการณ์ของโมดูล A คุณต้องมีผู้ฟังเหตุการณ์
ฉันจะเปลี่ยนคำถามของคุณและพูดว่า: เมื่อเหตุการณ์ตามไม่ใช่ทางออกที่เหมาะสมสำหรับแอปพลิเคชันเชิงวัตถุ? ฉันคิดว่าแอปพลิเคชัน OO ส่วนใหญ่จะได้รับประโยชน์หากได้รับการออกแบบในฐานะผู้ผลิตและผู้บริโภค
ในท้ายที่สุด "การเรียกใช้เมธอด" ในความเป็นจริงแล้วข้อความมาถึงที่วัตถุและวัตถุนั้นมีหน้าที่รับผิดชอบในการตัดสินใจว่าจะทำอะไรกับข้อความและทำการดำเนินการ นี่ไม่ชัดเจนในภาษาที่พิมพ์อย่างมากเช่น Java แต่จะชัดเจนมากขึ้นในภาษาแบบไดนามิกเช่น Ruby
อีกจุดที่น่าสนใจในการออกแบบแอปพลิเคชั่นตามเหตุการณ์คือโดยปกติส่วนประกอบภายในจะต้องถูกแยกและเชื่อมโยงกันอย่างเหมาะสมมิฉะนั้นรหัสจะกลายเป็นระเบียบอย่างรวดเร็วมาก ตัวอย่างเช่นฉันชอบแนวคิดของสถาปัตยกรรมแบบหกเหลี่ยมที่ใช้โดยอลิสแตร์ค้อเบิร์นโดยปกติแล้วรูปแบบนี้จะสร้างการห่อหุ้มและกองกำลังที่ดีขึ้น
ฉันคิดว่า (แต่ฉันอาจผิด) ที่เกี่ยวข้องกับแนวคิดการออกแบบการขับเคลื่อนด้วยโดเมนของDomain Eventsซึ่งคลาสโดเมนปล่อยกิจกรรมที่ถูกจับโดยวัตถุอื่นและวัตถุเหล่านี้ปล่อยกิจกรรมอื่น ๆ (คุณจะเห็นว่า มันกำลังจะเกิดขึ้น: D) สิ่งที่ฉันชอบเกี่ยวกับรูปแบบนี้คือสิ่งที่บอกว่าอินเตอร์เฟสควรเป็นแบบจำลองบทบาทไม่ใช่การนำไปใช้งาน
ขออภัยถ้าฉันไม่เข้าใจฉันกำลังทดลองรูปแบบเหล่านี้ในช่วงสองสามเดือนที่ผ่านมาด้วยผลลัพธ์ที่น่าทึ่ง แต่ฉันยังคงพยายามที่จะเข้าใจแนวคิดและเข้าถึงพวกเขาได้ไกลแค่ไหน
คิดเกี่ยวกับสิ่งที่คุณต้องทำหากผู้ฟังเหตุการณ์ (aka. รูปแบบการสังเกตการณ์) ไม่มีอยู่จริง
หากคุณมีวัตถุที่มีการอ้างอิงไปยังรายการของวัตถุอื่น ๆ และเรียกวิธีการที่พวกเขา ณ จุดที่กำหนดในกระบวนการคุณควรมีเหตุการณ์ที่แน่นอน
หากคุณมีการตั้งค่าสถานะบนวัตถุเพื่อบอกว่ามีบางสิ่งที่ทำไปแล้วและคุณกำลังดูการตั้งค่าสถานะนั้นจากวัตถุอื่นคุณควรใช้โมเดลที่ขับเคลื่อนด้วยเหตุการณ์
อย่างไรก็ตามอย่าสับสนระหว่างการโทรกลับ หากคุณเรียกใช้เมธอดบนออบเจ็กต์อื่นและส่งเมธอดไปที่ออบเจ็กต์ต้นทางเพื่อโทรกลับไปตามเวลาที่กำหนดคุณควรปล่อยให้เป็นแบบนั้นแทนที่จะใช้ตัวฟังเหตุการณ์