इवेंट संचालित कोड के रखरखाव को कैसे कम करें?


16

एक घटना आधारित घटक का उपयोग करते समय मैं अक्सर रखरखाव के चरण में कुछ दर्द महसूस करता हूं।

चूंकि निष्पादित कोड सभी के आसपास विभाजित है, इसलिए यह पता लगाना काफी कठिन हो सकता है कि सभी कोड भाग क्या होंगे जो रनटाइम में शामिल होंगे।

जब कोई नया ईवेंट हैंडलर जोड़ता है, तो यह समस्याओं को डीबग करने के लिए सूक्ष्म और कठिन हो सकता है।

टिप्पणियों से संपादित करें: यहां तक ​​कि बोर्ड पर कुछ अच्छे अभ्यासों के साथ, जैसे एप्लिकेशन वाइड इवेंट बस और हैंडलर ऐप के अन्य भाग में व्यवसाय का प्रतिनिधित्व करते हैं, एक ऐसा क्षण होता है जब कोड को पढ़ना मुश्किल हो जाता है क्योंकि इसमें बहुत कुछ होता है कई अलग-अलग स्थानों से पंजीकृत हैंडलर (विशेष रूप से सच है जब एक बस है)।

फिर अनुक्रम आरेख जटिल दिखना शुरू हो जाता है, यह पता लगाने के लिए समय व्यतीत होता है कि क्या हो रहा है और डिबगिंग सत्र गड़बड़ हो जाता है (हैंडलर प्रबंधक पर ब्रेकपॉइंट हैंडलर पर पुनरावृत्ति करते समय, विशेष रूप से async हैंडलर के साथ हर्षित और इसके शीर्ष पर कुछ फ़िल्टरिंग)।

//////////////
उदाहरण

मेरे पास एक सेवा है जो सर्वर पर कुछ डेटा पुनर्प्राप्त कर रही है। क्लाइंट पर हमारे पास एक बुनियादी घटक है जो कॉलबैक का उपयोग करके इस सेवा को कॉल कर रहा है। घटक के उपयोगकर्ताओं को विस्तार बिंदु प्रदान करने के लिए और विभिन्न घटकों के बीच युग्मन से बचने के लिए, हम कुछ घटनाओं को निकाल रहे हैं: क्वेरी भेजे जाने से पहले एक, जब जवाब वापस आ रहा है और एक विफलता के मामले में एक और। हमारे पास हैंडलर का एक मूल सेट है जो पूर्व-पंजीकृत हैं जो घटक के डिफ़ॉल्ट व्यवहार को प्रदान करते हैं।

अब घटक के उपयोगकर्ता (और हम घटक के उपयोगकर्ता भी हैं) व्यवहार पर कुछ परिवर्तन करने के लिए कुछ हैंडलर जोड़ सकते हैं (क्वेरी, लॉग, डेटा विश्लेषण, डेटा फ़िल्टरिंग, डेटा मालिश, यूआई फैंसी एनीमेशन, श्रृंखला एकाधिक अनुक्रमिक प्रश्नों को संशोधित करें) , जो कुछ)। तो कुछ संचालकों को कुछ अन्य लोगों से पहले / बाद में निष्पादित किया जाना चाहिए और वे आवेदन में बहुत सारे अलग-अलग प्रवेश बिंदुओं से पंजीकृत हैं।

थोड़ी देर बाद, ऐसा हो सकता है कि एक दर्जन या अधिक हैंडलर पंजीकृत हैं, और इसके साथ काम करना थकाऊ और खतरनाक हो सकता है।

यह डिजाइन उभरा क्योंकि वंशानुक्रम का उपयोग पूरी तरह से गड़बड़ होने लगा था। ईवेंट सिस्टम का उपयोग एक प्रकार की रचना में किया जाता है, जहां आपको अभी तक नहीं पता है कि आपके कंपोजिट क्या होंगे।

उदाहरण का अंत
//////////////

इसलिए मैं सोच रहा हूं कि दूसरे लोग इस तरह के कोड से कैसे निपट रहे हैं। इसे लिखते और पढ़ते दोनों।

क्या आपके पास कोई ऐसा तरीका या उपकरण है जो आपको बहुत दर्द के बिना इस तरह के कोड लिखने और बनाए रखने देता है?


आप मतलब है, घटना संचालकों से तर्क को दूर करने के अलावा ?
तेलस्टीन जूल

दस्तावेज़ क्या चल रहा है।

@ टेलस्टाइन, मुझे पूरी तरह से समझ में नहीं आ रहा है कि 'इवेंट हैंडलर से तर्क को दूर करने के अलावा' का क्या मतलब है।
गुइलुमे

@Thorbjoern: मेरा अपडेट देखें।
गुइलुमे

3
ऐसा लगता है कि आप नौकरी के लिए सही उपकरण का उपयोग नहीं कर रहे हैं? मेरा मतलब है, यदि आदेश मायने रखता है, तो आपको पहली बार आवेदन के उन हिस्सों के लिए सादे घटनाओं का उपयोग नहीं करना चाहिए। मूल रूप से अगर एक ठेठ बस प्रणाली में घटनाओं के क्रम पर सीमाएं हैं, तो यह अब एक सामान्य बस प्रणाली नहीं है, लेकिन आप अभी भी इस तरह का उपयोग कर रहे हैं। जिसका अर्थ है कि आपको आदेश को संभालने के लिए कुछ अतिरिक्त तर्क जोड़कर उस मुद्दे को संबोधित करने की आवश्यकता है। कम से कम, अगर मैं आपकी समस्या को सही ढंग से समझता हूं ..
जूल

जवाबों:


7

मैंने पाया है कि आंतरिक घटनाओं (विशेष रूप से, मनमाने ढंग से हटाने के साथ एक एलआईएफओ कतार) के ढेर का उपयोग करके घटनाओं को संचालित करने वाली प्रोग्रामिंग को सरल करता है। यह आपको एक "बाहरी घटना" के प्रसंस्करण को कई छोटी "आंतरिक घटनाओं" में विभाजित करने की अनुमति देता है, बीच में अच्छी तरह से परिभाषित स्थिति के साथ। अधिक जानकारी के लिए, इस प्रश्न का मेरा उत्तर देखें ।

यहां मैं एक सरल उदाहरण प्रस्तुत करता हूं जो इस पैटर्न द्वारा हल किया जाता है।

मान लीजिए कि आप कुछ सेवा करने के लिए ऑब्जेक्ट ए का उपयोग कर रहे हैं, और जब यह पूरा हो जाता है तो आपको सूचित करने के लिए कॉलबैक देता है। हालांकि, ए ऐसा है कि आपके कॉलबैक को कॉल करने के बाद, इसे कुछ और काम करने की आवश्यकता हो सकती है। उस कॉलबैक के भीतर एक खतरा उत्पन्न होता है, आप तय करते हैं कि आपको किसी और की आवश्यकता नहीं है, और आप इसे किसी तरह या किसी अन्य को नष्ट करते हैं। लेकिन आपके कॉलबैक रिटर्न के बाद A - अगर A से आपको कॉल किया जा रहा है, तो यह सुरक्षित रूप से पता नहीं लगा सकता है कि इसे नष्ट कर दिया गया था, शेष कार्य करने का प्रयास करने पर क्रैश हो सकता है।

नोट: यह सच है कि आप "विनाश" को किसी अन्य तरीके से कर सकते हैं, जैसे कि एक रिफरेक्ट को कम करना, लेकिन यह सिर्फ मध्यवर्ती राज्यों की ओर जाता है, और अतिरिक्त कोड और बग्स को संभालने से; A के लिए बेहतर है कि आप पूरी तरह से काम करना बंद कर दें, इसके बाद आपको किसी अन्य मध्यवर्ती स्थिति में जारी रखने की आवश्यकता नहीं है।

मेरे पैटर्न में, A बस आगे के कार्य को शेड्यूल लूप की LIFO कतार में एक आंतरिक घटना (नौकरी) को धक्का देकर करने की आवश्यकता है, फिर कॉलबैक पर कॉल करने के लिए आगे बढ़ें, और तुरंत इवेंट लूप पर लौटें । कोड का यह टुकड़ा अब कोई खतरा नहीं है, क्योंकि ए सिर्फ रिटर्न देता है। अब, यदि कॉलबैक ए को नष्ट नहीं करता है, तो धक्का दिया गया कार्य अंततः इवेंट लूप द्वारा अपने अतिरिक्त कार्य को करने के लिए निष्पादित किया जाएगा (कॉलबैक के बाद, और उसके सभी पुश किए गए कार्य, पुनरावर्ती)। दूसरी ओर, यदि कॉलबैक ए को नष्ट कर देता है, तो ए के विनाशकारी या डिनिट फ़ंक्शन को धकेल दिया गया कार्य स्टैक से निकाल सकता है।


7

मुझे लगता है कि उचित लॉगिंग काफी बड़ी मदद कर सकती है। सुनिश्चित करें कि फेंके गए / संभाले गए हर ईवेंट को कहीं लॉग किया गया है (आप इसके लिए लॉगिंग फ़्रेमवर्क का उपयोग कर सकते हैं)। जब आप डिबगिंग कर रहे होते हैं, तो बग होने पर अपने कोड के निष्पादन का सटीक क्रम देखने के लिए आप लॉग से सलाह ले सकते हैं । अक्सर यह वास्तव में समस्या के कारण को कम करने में मदद करेगा।


हाँ, यह एक उपयोगी सलाह है। उत्पादित लॉग की मात्रा तब भयावह हो सकती है (मैं एक बहुत ही जटिल रूप की घटना प्रसंस्करण में एक चक्र का कारण खोजने के लिए कुछ कठिन समय याद कर सकता हूं।)
गुइलूम

शायद एक समाधान एक अलग लॉग फ़ाइल के लिए दिलचस्प जानकारी लॉग करना है। इसके अलावा, आप प्रत्येक ईवेंट के लिए एक यूयूआईडी असाइन कर सकते हैं, जिससे आप प्रत्येक ईवेंट को अधिक आसानी से ट्रैक कर सकते हैं। आप कुछ रिपोर्टिंग टूल भी लिख सकते हैं जो आपको लॉग फ़ाइलों से विशिष्ट जानकारी निकालने की अनुमति देता है। (या वैकल्पिक रूप से, विभिन्न लॉग फ़ाइलों को अलग-अलग जानकारी लॉग करने के लिए कोड में स्विच का उपयोग करें)।
जियोर्जियो

3

इसलिए मैं सोच रहा हूं कि दूसरे लोग इस तरह के कोड से कैसे निपट रहे हैं। इसे लिखते और पढ़ते दोनों।

इवेंट संचालित प्रोग्रामिंग का मॉडल कुछ हद तक कोडिंग को सरल बनाता है। यह संभवतः पुरानी भाषाओं में उपयोग किए जाने वाले बड़े चयन (या केस) बयानों के प्रतिस्थापन के रूप में विकसित हुआ है और वीबी 3 जैसे प्रारंभिक दृश्य विकास वातावरण में लोकप्रियता प्राप्त की है (मुझे इतिहास पर उद्धरण न दें, मैंने इसकी जांच नहीं की)!

यदि घटना क्रम मायने रखता है और जब कई घटनाओं में 1 व्यावसायिक कार्रवाई विभाजित होती है, तो मॉडल एक दर्द बन जाता है। इस प्रक्रिया की शैली इस दृष्टिकोण के लाभों का उल्लंघन करती है। हर कीमत पर, संबंधित घटना में एक्शन कोड को संक्षिप्त बनाने की कोशिश करें और घटनाओं के भीतर से घटनाओं को न बढ़ाएं। यह तब GoTo से उत्पन्न स्पेगेटी की तुलना में कहीं अधिक खराब हो जाता है।

कभी-कभी डेवलपर्स जीयूआई कार्यक्षमता प्रदान करने के लिए उत्सुक होते हैं जिन्हें इस तरह की घटना निर्भरता की आवश्यकता होती है, लेकिन वास्तव में कोई वास्तविक विकल्प नहीं है जो कि काफी सरल है।

नीचे की रेखा यह है कि तकनीक खराब नहीं है अगर बुद्धिमानी से उपयोग किया जाता है।


क्या उनकी कोई वैकल्पिक डिजाइन 'स्पेगेटी से भी बदतर' से बचने के लिए है?
गिलियूम

मुझे यकीन नहीं है कि अपेक्षित GUI व्यवहार को सरल किए बिना एक आसान तरीका है, लेकिन यदि आप अपने सभी उपयोगकर्ता इंटरैक्शन को एक विंडो / पृष्ठ के साथ सूचीबद्ध करते हैं और प्रत्येक के लिए यह निर्धारित करता है कि आपका प्रोग्राम क्या करेगा, तो आप एक स्थान पर कोडिंग शुरू कर सकते हैं और निर्देशित कर सकते हैं अनुरोध के वास्तविक प्रसंस्करण के लिए ज़िम्मेदार उप-विधियों / विधियों के समूह के लिए कई घटनाएँ। कोड को अलग करना जो केवल GUI को उस कोड से सेवा प्रदान करता है जो बैक एंड प्रोसेसिंग में मदद करता है।
NoChance

इस संदेश को पोस्ट करने की आवश्यकता तब हुई जब मैं एक विरासत नरक से घटना के आधार पर कुछ करने के लिए आया था। कुछ बिंदु पर यह वास्तव में बेहतर है, लेकिन कुछ अन्य पर यह काफी बुरा है ... चूंकि मुझे पहले से ही कुछ जीयूआई में 'घटनाओं जंगली' के साथ कुछ परेशानी हुई है, मैं सोच रहा हूं कि इस तरह के रखरखाव को बेहतर बनाने के लिए क्या किया जा सकता है घटना कटा हुआ कोड।
गिलियूम

इवेंट-चालित प्रोग्रामिंग VB से कहीं अधिक पुरानी है; यह SunTools GUI में मौजूद था, और इससे पहले मुझे याद है कि यह सिमूला भाषा में बनाया गया था।
केविन क्लाइन

@Guillaume, मुझे लगता है कि आप सेवा से अधिक इंजीनियरिंग कर रहे हैं। मेरा उपरोक्त विवरण वास्तव में ज्यादातर GUI घटनाओं पर आधारित था। क्या आपको (वास्तव में) इस प्रकार के प्रसंस्करण की आवश्यकता है?
NoChance

3

मैं इस जवाब को अपडेट करना चाहता था क्योंकि मैंने "चपटे" और "चपटे" नियंत्रण प्रवाह के बाद कुछ यूरेका क्षणों को प्राप्त किया है और इस विषय पर कुछ नए विचार तैयार किए हैं।

कॉम्प्लेक्स साइड इफेक्ट्स बनाम कॉम्प्लेक्स कंट्रोल फ्लो

मैंने पाया है कि मेरा मस्तिष्क जटिल साइड इफेक्ट्स या जटिल ग्राफ-जैसे नियंत्रण प्रवाह को सहन कर सकता है जैसा कि आप आमतौर पर ईवेंट हैंडलिंग के साथ पाते हैं, लेकिन दोनों का कॉम्बो नहीं।

मैं आसानी से कोड के बारे में बता सकता हूं जो 4 अलग-अलग साइड इफेक्ट्स का कारण बनता है यदि वे एक बहुत ही सरल नियंत्रण प्रवाह के साथ लगाए जा रहे हैं, जैसे कि एक अनुक्रमिक forलूप। मेरा मस्तिष्क एक अनुक्रमिक लूप को सहन कर सकता है जो आकार बदलता है और तत्वों को पुन: उत्पन्न करता है, उन्हें एनिमेट करता है, उन्हें फिर से बनाता है और किसी प्रकार की सहायक स्थिति को अपडेट करता है। यह समझने के लिए काफी आसान है।

मैं वैसे ही एक जटिल नियंत्रण प्रवाह को समझ सकता हूं जैसा कि आप कैस्केडिंग घटनाओं के साथ प्राप्त कर सकते हैं या एक जटिल ग्राफ जैसी डेटा संरचना का पता लगा सकते हैं यदि इस प्रक्रिया में बस एक बहुत ही सरल साइड इफेक्ट चल रहा हो, जहां ऑर्डर थोड़ा सा भी मायने नहीं रखता है, जैसे चिह्न तत्व एक सरल अनुक्रमिक पाश में आस्थगित फैशन में संसाधित किया जाना है।

जहां मैं खो जाता हूं और भ्रमित और अभिभूत होता है जब आपके पास जटिल साइड इफेक्ट के कारण जटिल नियंत्रण प्रवाह होता है। उस स्थिति में जटिल नियंत्रण प्रवाह अग्रिम में भविष्यवाणी करना मुश्किल बना देता है जहां आप समाप्त होने जा रहे हैं जबकि जटिल साइड इफेक्ट्स यह भविष्यवाणी करना मुश्किल बनाते हैं कि वास्तव में परिणाम के रूप में क्या होने वाला है और किस क्रम में है। तो यह इन दो चीजों का संयोजन है जो इसे इतना असुविधाजनक बनाता है, भले ही कोड अभी पूरी तरह से ठीक काम करता है, लेकिन अवांछित दुष्प्रभावों के डर के बिना इसे बदलने के लिए यह बहुत डरावना है।

जटिल नियंत्रण प्रवाह के कारण कब / कहाँ चीजें होने जा रही हैं, इसके बारे में तर्क करना मुश्किल हो जाता है। यह केवल वास्तव में सिरदर्द-उत्प्रेरण बन जाता है अगर ये जटिल नियंत्रण प्रवाह साइड इफेक्ट्स के एक जटिल संयोजन को ट्रिगर कर रहे हैं जहां यह समझना महत्वपूर्ण है कि कब / कहाँ चीजें होती हैं, जैसे साइड इफेक्ट्स जिसमें किसी प्रकार का आदेश निर्भरता है जहां एक चीज अगले से पहले होनी चाहिए।

नियंत्रण प्रवाह या साइड इफेक्ट को सरल बनाएं

तो आप क्या करते हैं जब आप उपरोक्त परिदृश्य का सामना करते हैं, जिसे समझना मुश्किल है? रणनीति या तो नियंत्रण प्रवाह या साइड इफेक्ट को सरल बनाने के लिए है।

साइड इफेक्ट को सरल बनाने के लिए एक व्यापक रूप से लागू रणनीति आस्थगित प्रसंस्करण के पक्ष में है। एक उदाहरण के रूप में GUI आकार की घटना का उपयोग करना, सामान्य प्रलोभन GUI लेआउट को फिर से लागू करना, बच्चे के विगेट्स को फिर से आकार और आकार देना हो सकता है, लेआउट अनुप्रयोगों के एक और झरने को ट्रिगर करना और नियंत्रण को निरस्त करने के साथ-साथ पदानुक्रम को कम करना और पुन: व्यवस्थित करना, संभवतः कुछ ट्रिगर करना। विगेट्स के लिए अनोखी घटनाएँ जिनमें कस्टम आकार बदलने का व्यवहार होता है, जो अधिक घटनाओं को ट्रिगर करता है, जो जानता है, जहां आदि, इस सब को एक पास में करने की कोशिश करने के बजाय या इवेंट कतार को स्पैम करके, एक संभावित समाधान विजेट पदानुक्रम से नीचे उतरना है और चिह्नित करें कि किस विजेट को अपडेट किए जाने के लिए उनके लेआउट की आवश्यकता है। फिर बाद में, आस्थगित पास जिसमें एक सीधा अनुक्रमिक नियंत्रण प्रवाह होता है, विगेट्स के लिए सभी लेआउट को फिर से लागू करता है जिन्हें इसकी आवश्यकता होती है। फिर आप चिह्नित कर सकते हैं कि किस विजेट को पुन: अंकित करने की आवश्यकता है। फिर से एक नियंत्रण प्रवाह के साथ एक अनुक्रमिक आस्थगित पास में, redrawn होने की आवश्यकता के रूप में चिह्नित विगेट्स को फिर से दबाएं।

यह नियंत्रण प्रवाह और साइड इफेक्ट दोनों को सरल बनाने का प्रभाव है क्योंकि नियंत्रण प्रवाह सरल हो जाता है क्योंकि यह ग्राफ़ ट्रैवर्सल के दौरान पुनरावर्ती घटनाओं को कैस्केडिंग नहीं करता है। इसके बजाय कैस्केड आस्थगित अनुक्रमिक लूप में होते हैं जो तब एक और आस्थगित अनुक्रमिक लूप में संभाला जा सकता है। साइड इफेक्ट्स सरल हो जाते हैं, जहां से यह गणना करता है, अधिक जटिल ग्राफ़-जैसे नियंत्रण प्रवाह के दौरान, हम जो कुछ भी कर रहे हैं वह केवल चिह्नित कर रहा है कि आस्थगित अनुक्रमिक छोरों द्वारा संसाधित करने की आवश्यकता है जो अधिक जटिल साइड इफेक्ट्स को ट्रिगर करते हैं।

यह कुछ प्रसंस्करण ओवरहेड के साथ आता है, लेकिन यह समानांतर में इन स्थगित पासों को करने के लिए दरवाजे खोल सकता है, कह सकता है, संभवतः आपको प्रदर्शन शुरू होने की तुलना में इससे भी अधिक कुशल समाधान प्राप्त करने की अनुमति देता है। आमतौर पर प्रदर्शन ज्यादातर मामलों में एक चिंता का विषय नहीं होना चाहिए। सबसे महत्वपूर्ण बात, जबकि यह एक म्यूट अंतर की तरह लग सकता है, मैंने इसे कारण के लिए बहुत आसान पाया है। इससे यह अनुमान लगाना बहुत आसान हो जाता है कि क्या हो रहा है और कब हो रहा है, और मैं उस मूल्य को कम नहीं कर सकता हूं जो अधिक आसानी से समझने में सक्षम हो सकता है कि क्या हो रहा है।


2

मेरे लिए जो काम किया गया है वह अन्य घटनाओं के संदर्भ के बिना प्रत्येक घटना को अपने दम पर खड़ा कर रहा है। यदि वे अतुल्यकालिक रूप से आ रहे हैं, तो आपके पास कोई अनुक्रम नहीं है , इसलिए यह पता लगाने की कोशिश करना कि क्या क्रम व्यर्थ है, इसके अलावा असंभव है।

आप जो कुछ भी करते हैं, वह डेटा संरचनाओं का एक समूह है, जो किसी विशेष क्रम में एक दर्जन थ्रेड्स द्वारा पढ़ा और संशोधित और बनाया और हटाया जा रहा है। आपको अत्यधिक उचित थ्रेडेड प्रोग्रामिंग करना है, जो आसान नहीं है। आपको बहु-थिंकिंग के बारे में भी सोचना है, जैसे "इस घटना के साथ, मैं उस डेटा को देखने जा रहा हूं, जो किसी विशेष पल में है, जो पहले एक माइक्रोसेकंड था, इस संबंध में बिना किसी बदलाव के संबंध में। , और इस बात की परवाह किए बगैर कि 100 धागे मुझे ताला जारी करने के लिए क्या करने जा रहे हैं, वे इसे करने जा रहे हैं। फिर मैं इसके आधार पर अपने बदलाव करूंगा और जो भी मैं देखूंगा उसके बाद मैं कर रहा हूं। "

एक चीज जो मैं खुद कर रहा हूं, वह एक विशेष संग्रह के लिए स्कैन कर रही है और यह सुनिश्चित कर रही है कि संदर्भ और संग्रह दोनों (यदि थ्रेडसेफ़ नहीं है) सही ढंग से बंद हैं और अन्य डेटा के साथ सही ढंग से सिंक्रनाइज़ हैं। जैसे-जैसे अधिक घटनाओं को जोड़ा जाता है, यह राग बढ़ता जाता है। लेकिन अगर मैं घटनाओं के बीच के रिश्तों पर नज़र रख रहा था, तो वह बहुत तेजी से बढ़ेगा। इसके अलावा कभी-कभी बहुत सारे लॉकिंग को अपने तरीके से अलग किया जा सकता है, जो वास्तव में कोड को सरल बनाता है।

प्रत्येक थ्रेड को पूरी तरह से स्वतंत्र इकाई के रूप में व्यवहार करना मुश्किल है (हार्ड-कोर मल्टी-थ्रेडिंग के कारण) लेकिन संभव है। "स्केलेबल" वह शब्द हो सकता है जिसकी मुझे तलाश है। कई घटनाओं में दो बार केवल दो बार ज्यादा काम होता है, और शायद केवल 1.5 गुना ज्यादा। अधिक अतुल्यकालिक घटनाओं के समन्वय की कोशिश आपको जल्दी से दफन कर देगी।


मैंने अपना प्रश्न अपडेट कर दिया है। आप अनुक्रम और async सामान के बारे में पूरी तरह से सही हैं। आप एक ऐसे मामले को कैसे संभालेंगे जहां अन्य सभी घटनाओं को संसाधित करने के बाद घटना एक्स को निष्पादित किया जाना चाहिए? ऐसा लग रहा है कि मुझे एक अधिक जटिल हैंडलर प्रबंधक बनाना है, लेकिन मैं उपयोगकर्ताओं को बहुत अधिक जटिलता को उजागर करने से बचना चाहता हूं।
गिलियूम

आपके डेटा के सेट में, एक स्विच और कुछ फ़ील्ड हैं जो इवेंट X पढ़ने पर सेट होते हैं। जब अन्य सभी संसाधित होते हैं, तो आप स्विच की जांच करते हैं और जानते हैं कि आपको एक्स को संभालना है और आपके पास डेटा है। स्विच और डेटा को वास्तव में अपने दम पर खड़ा होना चाहिए। सेट होने पर, आपको यह सोचना चाहिए, "मुझे यह काम करना है," नहीं "मुझे एक्स को संभालना होगा।" अगली समस्या: आप कैसे जानते हैं कि घटनाएँ हो चुकी हैं? और क्या होगा अगर आपको 2 या अधिक इवेंट X मिले? सबसे खराब स्थिति, आप एक लूपिंग रखरखाव धागा चला सकते हैं जो स्थिति की जांच करता है और अपनी पहल पर कार्य कर सकता है। (3 सेकंड के लिए कोई इनपुट नहीं? एक्स स्विच सेट? फिर शटडाउन कोड चलाएं।
राल्फचैपिन

2

ऐसा लगता है कि आप स्टेट मशीन एंड इवेंट ड्रिवेन एक्टिविटीज की तलाश में हैं

हालाँकि, आप स्टेट मशीन मार्कअप वर्कफ़्लो नमूना को भी देखना चाहते हैं ।

यहाँ आप राज्य मशीन कार्यान्वयन का संक्षिप्त अवलोकन कर रहे हैं। एक राज्य मशीन वर्कफ़्लो में राज्यों के होते हैं। प्रत्येक राज्य एक या अधिक घटना संचालकों से बना होता है। प्रत्येक ईवेंट हैंडलर में पहली गतिविधि के रूप में विलंब या IEventActivity होनी चाहिए। प्रत्येक ईवेंट हैंडलर में एक SetStateActivity गतिविधि भी हो सकती है जिसका उपयोग एक राज्य से दूसरे राज्य में संक्रमण के लिए किया जाता है।

प्रत्येक राज्य मशीन वर्कफ़्लो में दो गुण होते हैं: InitialStateName और CompletedStateName। जब राज्य मशीन वर्कफ़्लो का एक उदाहरण बनाया जाता है, तो इसे InitialStateName गुण में डाल दिया जाता है। जब राज्य मशीन कंप्लीटस्टैटेनेम प्रॉपर्टी तक पहुंचती है, तो यह निष्पादन को पूरा करता है।


2
जब भी यह सैद्धांतिक रूप से प्रश्न का उत्तर दे सकता है, तो उत्तर के आवश्यक भागों को शामिल करना और संदर्भ के लिए लिंक प्रदान करना बेहतर होगा
थॉमस ओवेन्स

लेकिन यदि आपके पास प्रत्येक राज्य से जुड़े दर्जनों हैंडलर हैं, तो आप यह समझने के लिए ठीक नहीं होंगे कि क्या चल रहा है ... और हर घटना आधारित घटक को राज्य मशीन के रूप में वर्णित नहीं किया जा सकता है।
गिलियूम

1

इवेंट संचालित कोड वास्तविक समस्या नहीं है। मुझे लगता है कि मुझे संचालित कोड में तर्क के बाद भी कोई समस्या नहीं है, जहां कॉल-बैक को स्पष्ट रूप से परिभाषित किया गया है या इन-लाइन कॉल-बैक का उपयोग किया जाता है। उदाहरण के लिए टॉरनेडो में जनरेटर स्टाइल कॉलबैक का पालन करना बहुत आसान है।

डिबग करने के लिए असली मुश्किल क्या है गतिशील रूप से उत्पन्न फ़ंक्शन कॉल। एंटी (?) पैटर्न जिसे मैं नर्क से कॉल-बैक फैक्टरी कहूंगा। हालांकि, इस तरह के फंक्शन कारखाने पारंपरिक प्रवाह में डिबग करने के लिए समान रूप से कठिन हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.