การผูกมัดเหตุการณ์ถือเป็นแนวปฏิบัติที่ดีหรือไม่

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

กิจกรรมที่ผูกมัดจะทำให้ฉันสานต่อผู้ฟังเพิ่มเติมได้ในภายหลังด้วยความพยายามค่อนข้างต่ำ (อาจเป็นไปได้ว่าการละเมิด YAGNI รหัสของฉันจะประกอบไปด้วยองค์ประกอบที่เข้าใจง่ายซึ่งไม่ควรยากสำหรับคนอื่นที่จะเข้าใจ

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

กิจกรรมผูกมัดเป็นความคิดที่ดี^TMหรือไม่ หากไม่เป็นเช่นนั้นวิธีการอื่นในการเก็บรหัสที่เกี่ยวข้องกับเหตุการณ์ทำให้เกิดความรก?

เป็นสิ่งที่ดีหรือไม่

มันเป็นหนึ่งในสิ่งเหล่านั้นที่ดูเหมือนจะเป็นความคิดที่ดีจริงๆจนกว่าคุณจะใช้มัน

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

พวกมันยากมากในการดีบักและใช้เหตุผลเกี่ยวกับโค้ด

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

ถึงกระนั้นฉันก็พบว่าบ่อยครั้งที่ฉันยอมรับผู้รับมอบอำนาจในคอนสตรัคเตอร์สำหรับพฤติกรรมที่สามารถขยายได้มากกว่าปล่อยให้พฤติกรรมตามอำเภอใจทำงานในเวลาจริง

การผูกมัดเหตุการณ์เป็นความคิดที่ดีถ้า

• โดยทั่วไปเหมาะสมกับสถานการณ์ของคุณ ตัวอย่างง่ายๆคือการกระทำ UI ของผู้ใช้ที่เรียกใช้เหตุการณ์ภาพอื่น ๆ
• แต่ละเหตุการณ์มีในตัวและสามารถจัดการได้ คุณไม่ต้องการให้โซลูชันยุ่งยากเกินไป
• การไหลของการควบคุมง่ายต่อการติดตาม จะต้องมีการติดตั้งบนแพลตฟอร์มและในภาษาที่ง่ายสำหรับนักพัฒนาที่จะเดินผ่าน หากคุณจำเป็นต้องติดตามวิธี "เวทมนต์" เพื่อติดตามสิ่งที่เกิดขึ้นคุณกำลังลงเส้นทางที่ผิด

มันสำคัญมากที่จะต้องคิดวิธีแก้ปัญหาและสรุปบางสิ่งก่อนเริ่มสร้างระบบ ตัวอย่างเช่นในภาษา OO คุณควรมีอินเทอร์เฟซพื้นฐานหรือคลาสนามธรรมเป็นพื้นฐานสำหรับเหตุการณ์ทั้งหมด คลาสนั้นควรรวมสิ่งต่าง ๆ เช่นการบันทึก / การดีบัก คุณอาจต้องการคลาสการจัดการเหตุการณ์ทั่วไปสำหรับการจัดการความล้มเหลวอย่างสง่างาม

พูดจากมุมมองของคนที่เคยใช้เวลาสองสามวันในการติดตามข้อผิดพลาดที่เกี่ยวข้องกับห่วงโซ่เหตุการณ์นี้เป็นความคิดที่แย่มาก (SM) คุณกำลังซ่อนโฟลว์ควบคุมของคุณซึ่ง (ตามที่คุณระบุไว้) ซึ่งสามารถทำการดีบักฝันร้ายได้ สถานการณ์ที่ฉันเกิดขึ้นเมื่อมีคนเพิ่มรหัสการจัดการข้อผิดพลาดซึ่งรีเซ็ตการควบคุม สิ่งนี้นำไปสู่สายโซ่ของonPropertyChangeตัวจัดการที่ทำให้การควบคุมสดชื่นขึ้นซึ่งมีตัวจัดการข้อผิดพลาดซึ่งนำไปสู่การรีเซ็ตตัวควบคุมอื่นอีกครั้งและอื่น ๆ โดยพื้นฐานแล้ว UI จะล็อค CPU ไว้ที่ 100%

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

การนำเหตุการณ์ไปปฏิบัติได้ดีนั้นทำได้ยากด้วยเหตุผลทั้งหมดที่กล่าวถึงโดยคนอื่น

อย่างไรก็ตามมันยังเป็นหลักฐานพื้นฐานของกฎส่วนใหญ่ JBoss Drools, IBM jRules, PegaSystems, Corticon และ FICO Blaze Advisor เป็นระบบการจัดการกฎทางธุรกิจที่สำคัญทั้งหมด (BRMS) ที่อนุญาตให้ผู้ใช้ประกาศกฎที่เปิดใช้งานตามเหตุการณ์ที่เกิดขึ้นในระบบ ทั้งไปข้างหน้าและถอยหลังผูกมัดเป็นไปได้และเป็นไปได้

ภาษาโปรล็อกและอนุพันธ์มีพื้นฐานมาจากแนวคิดเดียวกัน

อัลกอริธึมที่เกี่ยวข้องนั้นไม่ง่ายการดีบั๊กอาจเป็นความเจ็บปวด

ข้อเสียเปรียบอย่างหนึ่งที่อาจเกิดขึ้นคือมันค่อนข้างง่ายที่จะจบลงด้วยการวนซ้ำการอัพเดทโดยไม่ตั้งใจ เช่น A -> B -> C -> A -> B ...

อีกวิธีหนึ่งคือการสร้างเหตุการณ์ประกอบที่รับผิดชอบในการดับลำดับเหตุการณ์ ซึ่งหมายความว่าคุณไม่ควรติดอยู่ในวงวนและให้ที่เดียวเพื่อรับข้อผิดพลาด / ฯลฯ ฉันเคยประสบความสำเร็จในเรื่องนี้แม้ว่าจะไม่ได้ใช้มันเพื่อสิ่งที่ซับซ้อนเป็นพิเศษ (ยัง!)