इवेंट-संचालित प्रोग्रामिंग: यह कब लायक है?

Question

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

मैं एक छोटा एप्लिकेशन विकसित कर रहा हूं। यह एक सरल ऐप है, और अधिकांश भाग के लिए इसकी कार्यक्षमता बुनियादी CRUD है।

कुछ घटनाओं पर (कुछ डेटा को संशोधित करते समय) एप्लिकेशन को फ़ाइल में उक्त डेटा की एक स्थानीय प्रतिलिपि लिखनी होगी। मुझे इस बारे में निश्चित नहीं है कि इसे लागू करने का सबसे अच्छा तरीका क्या है। हाँ मैं:

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

इस मामले में सबसे अच्छा तरीका क्या है?

Comments

मैं कहूंगा कि अपने आप को कुछ भी लागू न करें - बस एक मौजूदा घटना बस का उपयोग करें। यह जीवन को बहुत सरल बना देगा ...

— बोरिस स्पाइडर

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

— पीटर बी

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

— Thorbjørn Ravn Andersen

वहाँ है घटना पर ही आधारित है और घटना के आधार पर के बीच एक अंतर। उदाहरण के लिए देखें अत्यधिक विचारोत्तेजक .NET रॉक्स पॉडकास्ट एपिसोड 355 टेड फ़ॉइसन के साथ, टेड फ़ॉज़न फ़ॉर्म्स टू द लिमिट! ( डायरेक्ट डाउनलोड URL ) और पुस्तक इवेंट-आधारित प्रोग्रामिंग: घटनाओं को सीमा तक ले जाना ।

— पीटर मॉर्टेंसन

टेड फैसन के साथ साक्षात्कार 13 मिनट 10 सेकंड में शुरू होता है।

— पीटर मोर्टेंसन

Answer 1

KISS सिद्धांत का पालन करें: यह रखें, सरल बेवकूफ, या YAGNI सिद्धांत: आप यह आवश्यकता के लिए जा रहे नहीं है।

आप इस तरह कोड लिख सकते हैं:

void updateSpecialData() {
    // do the update.
    backupData();
}

या आप कोड लिख सकते हैं जैसे:

void updateSpecialData() {
     // do the update.
     emit SpecialDataUpdated();
}

void SpecialDataUpdatedHandler() {
     backupData();
}

void configureEventHandlers() {
     connect(SpecialDataUpdate, SpecialDataUpdatedHandler);
}

अन्यथा करने के लिए एक सम्मोहक कारण की अनुपस्थिति में, सरल मार्ग का पालन करें। इवेंट हैंडलिंग जैसी तकनीक शक्तिशाली हैं, लेकिन वे आपके कोड की जटिलता को बढ़ाते हैं। इसे काम करने के लिए अधिक कोड की आवश्यकता होती है, और यह आपके कोड में वही होता है जो पालन करना कठिन होता है।

घटनाक्रम सही स्थिति में बहुत गंभीर (घटनाओं के बिना यूआई प्रोग्रामिंग के लिए कोशिश कर रहा कल्पना!) कर रहे हैं लेकिन उन्हें प्रयोग नहीं करते जब आप चुंबन या YAGNI कर सकते हैं बजाय।

Comments

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

— NoChance

Answer 2

उदाहरण आप एक साधारण डेटा का वर्णन करते हैं, जहां संशोधन कुछ प्रभाव को ट्रिगर करता है पूरी तरह से पर्यवेक्षक डिजाइन पैटर्न के साथ लागू किया जा सकता है :

• यह पूर्ण ईवेंट संचालित कोड की तुलना में लागू करने और बनाए रखने के लिए सरल है।
• विषय और पर्यवेक्षक के बीच युग्मन सार हो सकता है, जो चिंताओं को अलग करने की सुविधा प्रदान करता है।
• यह एक से कई संबंधों के लिए आदर्श है (विषयों में एक या कई पर्यवेक्षक हैं)।

इवेंट संचालित दृष्टिकोण अधिक जटिल परिदृश्यों के लिए अपने निवेश के लायक है, जब कई-से-कई संदर्भों में कई अलग-अलग इंटरैक्शन हो सकते हैं, या यदि श्रृंखला प्रतिक्रियाओं की परिकल्पना की जाती है (जैसे एक विषय एक पर्यवेक्षक को सूचित करता है, जो किसी मामले में संशोधित करना चाहता है। विषय या अन्य विषय)

Comments

मैं उलझन में हूं, क्या घटनाओं को लागू करने का सिर्फ एक तरीका नहीं है?

— svick

@ मुझे ऐसा नहीं लगता। में घटना चालित प्रोग्रामिंग आप एक मुख्य पाश है कि कई रिश्ते के लिए कई प्रक्रियाओं की घटनाओं, decoupled प्रेषकों और पर्यवेक्षकों के साथ। मुझे लगता है कि पर्यवेक्षक एक विशेष प्रकार की घटना को संसाधित करके योगदान दे सकता है, लेकिन आप केवल पर्यवेक्षक के साथ ईडीपी के पूर्ण स्पेक्ट्रम को प्राप्त नहीं कर सकते। मुझे लगता है कि इस तथ्य से भ्रम होता है कि घटना संचालित सॉफ्टवेयर में, पर्यवेक्षकों को कभी-कभी घटना प्रसंस्करण के शीर्ष पर लागू किया जाता है (आमतौर पर एमयूसी एक जीयूआई के साथ)

— क्रिस्टोफ

Answer 3

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

घटनाएँ निश्चित रूप से OO में सबसे महत्वपूर्ण उपकरणों में से एक हैं (एलन के अनुसार - वस्तुएं संदेश भेजकर और प्राप्त करके संवाद करती हैं )। यदि आप ऐसी भाषा का उपयोग करते हैं, जो घटनाओं के समर्थन में अंतर्निहित है, या प्रथम श्रेणी के नागरिकों के रूप में कार्य करता है, तो उनका उपयोग करना एक बिना दिमाग वाला है।

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

क्या यह एक छोटे से आवेदन में सार्थक है? मैं निश्चित रूप से हां कहूंगा ।

• कक्षाओं को एक-दूसरे से अलग रखने से आपकी कक्षा पर निर्भरता का ग्राफ साफ रहता है।
• बिना किसी ठोस निर्भरता वाली कक्षाओं को परीक्षणों में अन्य वर्गों के लिए विचार किए बिना अलगाव में परीक्षण किया जा सकता है।
• बिना किसी ठोस निर्भरता वाली कक्षाओं को पूर्ण कवरेज के लिए कम इकाई परीक्षणों की आवश्यकता होती है।

यदि आप सोच रहे हैं "ओह, लेकिन यह वास्तव में केवल एक बहुत छोटा अनुप्रयोग है, तो यह वास्तव में बहुत मायने नहीं रखता है" , विचार करें:

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

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

वास्तव में, अलगाव में अपनी शिथिल-युग्मित कक्षाओं के परीक्षण में यूनिट में बचाए गए समय को इन वर्गों के लिए डिकॉउप्लिंग करने में लगने वाले किसी भी अतिरिक्त समय का प्रति-संतुलन करना चाहिए।

Answer 4

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

परिणामस्वरूप कोड सीधे फ़ाइल-जनरेटिंग कोड को कॉल करने की तुलना में कम से कम अधिक जटिल होगा, लेकिन असंबंधित घटकों के तंग युग्मन की कमियों के बिना।

जो आपको "YAGNI" के लिए डिकॉउलिंग किए बिना "दोनों दुनिया के सर्वश्रेष्ठ" लाएगा।

Comments

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

— रबरडैक

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

— डॉक ब्राउन

एक निष्पक्ष बयान, लेकिन यह एक टूटी हुई खिड़की की तरह मुझे लगता है।

— रबरडैक

@ रबरडैक: प्रकाशक / ग्राहक यांत्रिकी के साथ एक पूर्ण पर्यवेक्षक जोड़ना, "बस के मामले में", जब इसकी वास्तव में आवश्यकता नहीं होती है, तो मुझे लगता है कि यह ओवरगिनरिंग की तरह है - यह बेहतर नहीं है।

— डॉक्टर ब्राउन

मैं असहमत नहीं हूं कि यह इंजीनियरिंग से अधिक हो सकता है। मुझे शायद ऐसा लगता है कि मैं ऐसा करता हूं क्योंकि यह मेरी पसंद के ढेर में लागू करने के लिए तुच्छ है। वैसे भी, हम सिर्फ असहमत होने के लिए सहमत होंगे?

— रबरडक