🤲🏻 🍪 👩‍🎤 C # प्रोग्रामिंग प्रतिमान बदलाव, संकेतों और कतारों में बदलाव (स्लॉट) 🤵🏾 😶 🤙🏿

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

वर्तमान प्रतिमान के साथ क्या गलत है

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

हां, और अभी भी ऐसा कुछ है कि प्रोसेसर के विकास के साथ अधिक से अधिक प्रासंगिक हो जाता है, यह अतुल्यकालिक है, इस दिशा में microsoft बहुत अच्छा करता है, वही PLINQ, किसी भी तरह की चीनी का इंतजार करता है, लेकिन यह सब वैसे भी OOP के सामान्य ढांचे के भीतर किया जाता है, और हम आपको अभी भी थ्रेड्स स्वयं बनाने हैं, भले ही कार्यों के रूप में, लेकिन अपने आप से। जब संसाधन अनावश्यक हो जाते हैं, तो आपको यह निर्धारित करने के लिए कार्यों को पूरा करने की आवश्यकता है।

सामान्य तौर पर, यह सब धीरे-धीरे परेशान करता है, प्रत्येक नई परियोजना में समान चीजों को लिखना बहुत आलसी हो जाता है, जब कार्य के तर्क पर ध्यान देना अधिक सही होगा।

खेल के नए नियमों का औपचारिककरण

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

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

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

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

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

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

नए नियम लागू करना

प्रारंभ:

//      -   [rtSignalParticipator] rtSignalCore.AppendAssembly(Assembly.GetEntryAssembly());

 //  ,     -,     [rtSignalParticipator]   rtSignalCore.AppendTypeInstance(new FileHandler());

एक गणना जिसका मान सिग्नल के रूप में उपयोग किया जाता है:

 /// <summary> ///    /// </summary> public enum BufferSignal { /// <summary> ///      /// </summary> FileInBuffer }

कक्षा का एक उदाहरण (लेख के अंत में कोड का लिंक, नीचे दिए गए कार्य से कोड स्वयं) सिग्नल हैंडलर युक्त:

 //       , //         [rtSignalParticipator] class FileHandler { //       //   BufferSignal.FileInBuffer //       [rtSignalAsyncHanlder(BufferSignal.FileInBuffer)] void ProcessFileInBuffer(rtSignal signal) { ... } }

सिग्नल की पीढ़ी और सभी सिंक्रोनस और एसिंक्रोनस हैंडलर द्वारा सिग्नल प्रोसेसिंग को पूरा करने के लिए एक हैंडलर का उदाहरण।

 [rtSignalAsyncHanlder(DirectoryWatcherSignal.ChangedDirectory)] void NewFileHandler(rtSignal signal) { string path = (string)signal.State; ...................................................................... //            //      rtSignalCore.Signal(BufferSignal.FileInBuffer, filePath); ...................................................................... } /// <summary> ///           /// </summary> [rtSignalCompletedAsyncHanlder(BufferSignal.FileInBuffer)] void RemoveFileFromBuffer(rtSignal signal) { string path = (string)signal.State; if (File.Exists(path)) File.Delete(path); }

सिग्नल हैंडलर निर्दिष्ट करने के लिए निम्नलिखित विशेषताएं उपलब्ध हैं:

[rtSignalHanlder (सिग्नलआईडी)] - सिग्नल हैंडलर की विशेषता जिसे सिंक्रोनस कहा जाएगा
[rtSignalAsyncHanlder (सिग्नलआईडी)] - सिग्नल हैंडलर की विशेषता जिसे एसिंक्रोनसली कहा जाएगा
[rtSignalCompletedHanlder (सिग्नलआईडी)] - सिग्नल प्राप्त करने की विधि की विशेषता जब सभी सिग्नल हैंडलर ने अपना काम पूरा कर लिया है (एसिंक्रोनस सहित)
[rtSignalCompletedAsyncHanlder (सिग्नलआईडी)] - सिग्नल प्राप्त करने की विधि की विशेषता, जब सभी सिग्नल हैंडलर ने अपना काम पूरा कर लिया है (एसिंक्रोनस सहित), विधि अतुल्यकालिक रूप से चलती है

सिग्नल उत्पन्न करने के लिए, निम्न प्रारूप का उपयोग किया जाता है:

 rtSignalCore.Signal();

या

 rtSignalCore.Signal(, _);

शायद नीचे आने तक किसी चीज के साथ आने लायक।

संकेतों का उपयोग करके दृष्टिकोण को क्या हल करता है

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

हम व्यवहार में लाने की कोशिश करते हैं

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

कोई संकेत के मामले में, रूपरेखा

संकेतों का उपयोग करना, जहां कक्षाएं एक-दूसरे के तरीकों और घटनाओं के बारे में नहीं जानते हैं, और आमतौर पर पर्यावरण के बारे में नहीं जानते हैं:

11210 छोटी फ़ाइलों पर परीक्षण के लिए प्रोफाइलर से रेखांकन:
कोई संकेत नहीं:

संकेतों का उपयोग करना:

रेखांकन और वास्तविक उपयोग बताते हैं कि संकेतों की शुरूआत ने प्रदर्शन को कोई नुकसान नहीं पहुंचाया, बल्कि, इसके विपरीत, फाइलों की संख्या की परवाह किए बिना प्रसंस्करण स्थिर है।

निष्कर्ष।

एक बार फिर मुझे C # भाषा की सार्वभौमिकता पर यकीन हो गया, वास्तव में इसे किसी भी प्रतिमान का उपयोग करके प्रोग्राम किया जा सकता है, और यदि नहीं, तो इसे वांछित स्थिति में समाप्त करें।

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

प्रकाशन से पहले, मुझे क्यूटी में संकेतों और स्लॉट्स पर सामग्री मिली, सामान्य तौर पर, विचार समान हैं, लेकिन क्यूटी में मुझे यह नहीं मिला कि सभी स्लॉट से सिग्नल प्रोसेसिंग के अंत का तथ्य निर्धारित करना संभव है या नहीं।

मुझे नहीं पता कि क्या पहले से ही .NET पर एक समान मॉडल को लागू करने का प्रयास किया गया है, यदि आपने लिंक साझा किए हैं, तो यह दृष्टिकोणों की तुलना करना दिलचस्प है।

स्रोत पर परियोजना (अंग्रेजी के साथ सब कुछ खराब है, अगर आपको वहां त्रुटियां मिलती हैं, तो कृपया सदस्यता समाप्त करें)

UPD # 1: सिग्नल जनरेशन और हैंडलर पर एक विशिष्ट नोट के लिए, उपयोगकर्ता मेयरोवप के लिए धन्यवाद, अब आप किसी भी प्रकार के तर्क, किसी भी प्रकार के हैंडलर लिख सकते हैं, और सिग्नल उत्पन्न करते समय इन तर्कों को पारित कर सकते हैं (रनटाइम में संचरित प्रकारों के पत्राचार की जांच के साथ)।
उदाहरण:

कोई तर्क नहीं

 //  rtSignalCore.Signal(SignalIdentifierEnum.One); ................... //  [rtSignalHanlder(SignalIdentifierEnum.One)] void HandlerSignalClassBOne()

प्रकार स्ट्रिंग के एक तर्क को पारित करने के साथ एक उदाहरण

 //  "Hello world".SendSignal(SignalIdentifierEnum.One); ................... //  [rtSignalHanlder(SignalIdentifierEnum.One)] void HandlerSignalClassBOne(string line)

दो तर्क उदाहरण

 //  rtSignalCore.Signal(SignalIdentifierEnum.One, filePath, new FileInfo(filePath)); ................... //  [rtSignalHanlder(SignalIdentifierEnum.One)] void HandlerSignalClassBOne(string filePath, FileInfo file)

परीक्षणों में प्रदर्शन में गिरावट नहीं देखी गई।