एक मोबाइल गेम के लिए वास्तु समाधान। भाग 3: जेट जोर पर देखें

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

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

एक मोबाइल गेम के लिए वास्तु समाधान। भाग 1: मॉडल
एक मोबाइल गेम के लिए वास्तु समाधान। भाग 2: कमान और उनकी कतारें

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

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

var observable = new ChildControl(FCPlayerModel.ASSIGNED, Player); observable.onChange(i => Assigned.text = i.ToString()) 

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

 Player.Get(c, FCPlayerModel.ASSIGNED).Action(c, i => Assigned.text = i.ToString()); 

बहुत बेहतर है, लेकिन यह सब नहीं है। मॉडल फ़ील्ड को टेक्स्ट फ़ील्ड में स्थानांतरित करना एक ऐसा लगातार और विशिष्ट ऑपरेशन है जो हम इसके लिए एक अलग आवरण फ़ंक्शन बनाएंगे। अब यह काफी संक्षेप में और अच्छी तरह से पता चला है, जैसा कि मुझे लगता है।

 Player.Get(c, FCPlayerModel.ASSIGNED).SetText(c, Assigned); 

यहां मैंने मुख्य विचार दिखाया, जिसे मैं अपने जीवन के बाकी हिस्सों के लिए इंटरफेस बनाते समय निर्देशित करूंगा: "यदि एक प्रोग्रामर को कम से कम दो बार कुछ करना है, तो इसे एक विशेष सुविधाजनक और छोटे फ़ंक्शन में लपेटें।"

कचरा संग्रह

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

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

 Player.Get(FCPlayerModel.ASSIGNED).SetText(Assigned).AddTo(this); 

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

वास्तव में, आप गंदे यूनिटी हैक का उपयोग कर सकते हैं और दृश्य में किसी भी अतिरिक्त कोड के बिना कर सकते हैं:

 public static T AddTo<T>(this T disposable, Component component) where T : IDisposable { var composite = new CompositeDisposable(disposable); Observable .EveryUpdate() .Where(_ => component == null) .Subscribe(_ => composite.Dispose()) .AddTo(composite); return disposable; } 

जैसा कि आप जानते हैं, Unicomponent Component या GameObject in Unity का एक लिंक अशक्त है। लेकिन आपको यह समझने की आवश्यकता है कि यह हकोकॉस्टाइल नियंत्रण की प्रत्येक श्रृंखला के लिए एक अद्यतन श्रोता बनाता है जो नष्ट हो रहा है, और यह पहले से ही थोड़ा विनम्रता से है।

मॉडल स्वतंत्र इंटरफ़ेस

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

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

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

सूची नियंत्रण

एक विशिष्ट स्थिति तब होती है जब मॉडल में कुछ तत्वों की सूची होती है। चूंकि मैं चाहता हूं कि सब कुछ बहुत आसानी से किया जाए, और अधिमानतः एक ही लाइन पर, मैं उन सूचियों के लिए भी कुछ करना चाहता था जिन्हें संभालना सुविधाजनक होगा। एक पंक्ति संभव है, लेकिन यह असुविधाजनक रूप से लंबा हो जाता है। व्यावहारिक रूप से, यह पता चला कि लगभग पूरी विविधता केवल दो प्रकार के नियंत्रणों से आच्छादित है। पहले एक संग्रह की स्थिति पर नज़र रखता है और तीन लंबो कार्यों को कॉल करता है, पहले को तब बुलाया जाता है जब संग्रह में कुछ तत्व जोड़ा जाता है, दूसरा जब तत्व संग्रह छोड़ देता है, और अंत में तीसरा तब कहा जाता है जब संग्रह के तत्व क्रम बदलते हैं। दूसरा सबसे सामान्य प्रकार का नियंत्रण सूची की निगरानी करता है, और इसमें से सदस्यता का स्रोत है - एक विशिष्ट संख्या वाले पृष्ठ। अर्थात्, उदाहरण के लिए, यह 102 तत्वों की लंबाई के साथ एक सूची का अनुसरण करता है, और यह स्वयं 20 से 29 वें तक 10 तत्वों की सूची देता है। और उत्पन्न होने वाली घटनाएं बिल्कुल वैसी ही होती हैं जैसे कि वह एक सूची हो।

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

अधिक जटिल नियंत्रण

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

 item.Get(c, FCUnitItem.COST).Join(c, Player.Get(c, MONEY)).Func(c, (cost, money) => cost <= money).SetActive(c, BuyButton); 

वास्तव में, स्थिति इतनी विशिष्ट है कि मेरे सिद्धांत के अनुसार इसके लिए एक तैयार-निर्मित आवरण है, लेकिन फिर मैंने इसकी सामग्री दिखाई।

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

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

वास्तव में, प्रोजेक्ट में वास्तविक आवरण दो बटन को एक इनपुट के रूप में स्वीकार करता है, एक मामले के लिए जब पैसा होता है और दूसरा जब पर्याप्त पैसा नहीं होता है, और "खरीदें मुद्राओं" को खोलने के लिए कमांड मोडल विंडो भी दूसरे बटन पर लटका होता है। और यह सब एक सरल रेखा में है।

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

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

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

एकाधिक विचारों के लिए एक डेटा स्रोत

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

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

यह एक स्पष्ट समाधान प्रतीत होता है, लेकिन मैंने इस स्थिति के चारों ओर एक विचित्र नृत्य के साथ एक अजीब कोड पर पर्याप्त कोड में देखा, और इसके बारे में लिखना आवश्यक माना।

विशेष मामला: बहुत सारी निर्भरता के एक नरक के साथ नियंत्रण

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

UniRX रेडी लाइब्रेरी

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

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

सामान्य तौर पर, यदि आप पहले से ही जानते हैं कि UniRX का उपयोग कैसे किया जाता है, तो मैं इसे आपके लिए विशेष रूप से IObservable मॉडल के लिए बनाऊंगा, और आप अपनी पसंदीदा लाइब्रेरी की ट्रम्प सुविधाओं का उपयोग कर सकते हैं, जहाँ आपको इसकी आवश्यकता है, लेकिन बाकी के लिए मेरा सुझाव है कि केवल तेज कारों और टैंकों से कारों का निर्माण जमीन पर न करें। कि दोनों के पहिए हैं।

लेख के अंत में, मेरे पास है, प्रिय पाठकों, पारंपरिक प्रश्न जो मेरे लिए बहुत महत्वपूर्ण हैं, सुंदर के बारे में मेरे विचार, और मेरे वैज्ञानिक और तकनीकी कार्यों के विकास के लिए संभावनाओं के लिए।