👨🏼‍🎤 🌩️ 🎄 पर्यवेक्षकों के लिए मानसिक प्रतिक्रियाशील प्रोग्रामिंग मॉडल ⚱️ 👨🏿‍🏫 ↖️

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

अस्वीकरण

( ) — , . , .
, : , . , , .
.

लेकिन पहले, यह बताइए कि लेख के शीर्षक में जिन मानसिक मॉडल और वरिष्ठताओं का उल्लेख किया गया है, उन्हें इसके साथ क्या करना है ...

मानसिक मॉडल के बारे में

, , , . , .
, , (. [1], [2])
? , , . (), , , . , , «», «» « » .
, , (), , - ().

और यहाँ मालिक हैं ...

. «» «» , : . ( , «» , ).
, «» , , , , , . , . «» «». , , , .
, , , .., () — , , .
, .

प्रतिक्रियाशील प्रोग्रामिंग को आपके प्रोजेक्ट की आवश्यकता क्यों है?

आरपी से अपरिचित कई लोग शुरू में उस पर संदेह कर रहे हैं, संदेह है कि यह सिर्फ एक और खाली फैशन है, जो कुछ सुंदर शब्दों में शामिल है। विशेष रूप से जब वे सीखते हैं कि आप आरपी का मूल्यांकन केवल कोशिश करके कर सकते हैं। और यह कोशिश करने के लिए महंगा है, क्योंकि उच्च प्रवेश सीमा है। हम ओओपी के साथ रहते और रहते थे, इससे क्या गायब है?
मुझे इस विषय पर अपना दृष्टिकोण प्रस्तुत करने दीजिए।
प्रोग्रामिंग के भोर में, जब अधिकांश कार्यक्रम सीधे विधानसभा भाषा में लिखे गए थे, प्रोग्रामर की मुख्य कार्य अवधारणा (मानसिक मॉडल का एक तत्व) एक निर्देश, या एक भाषा कमांड थी। कुछ (आदिम) डेटा एक कमांड या निर्देश के इनपुट को खिलाया जाता है। निर्देश प्रक्रिया और कुछ आउटपुट डेटा जारी करता है। फोरट्रान जैसी पहली प्रक्रियात्मक प्रोग्रामिंग भाषाओं की उपस्थिति ने मामले का सार नहीं बदला। बस डेटा और प्रदर्शन किए गए कार्य (प्रारंभिक आदेशों के अनुक्रम के रूप में) अधिक जटिल हो गए हैं।
समय के साथ, यह स्पष्ट हो गया कि यह अवधारणा दुनिया की वास्तविकताओं के अनुरूप नहीं है। बहुत सारे डेटा हो सकते हैं, उन्हें संरचना करना मुश्किल हो सकता है। दोनों डेटा और उनके आसपास की कार्यक्षमता को भागों में विभाजित करने, अलग-अलग विकसित करने और बनाए रखने और एक साथ उपयोग करने के लिए अच्छा होगा।
OOP ने इन समस्याओं को कई तरीकों से हल किया। एक विशिष्ट ओओपी प्रोग्रामर के मानसिक मॉडल की इकाई एक ऐसी वस्तु है जिसमें डेटा छिपा हुआ है (एनकैप्सुलेटेड) है और फ़ंक्शन के सेट के रूप में इस डेटा तक पहुंच इंटरफ़ेस है।
ओओपी ने कई विनिर्माण और अन्य प्रक्रियाओं के स्वचालन और कम्प्यूटरीकरण में एक बड़ी भूमिका निभाई है। और इसके साथ ही, उनकी कमजोरियों को उजागर किया गया।
दुर्भाग्य से, OOP में इस तरह की प्रक्रिया की कोई अवधारणा नहीं है।
उन्होंने विभिन्न पहलुओं पर ध्यान केंद्रित करते हुए, विभिन्न तरीकों से स्थिति को बेहतर बनाने की कोशिश की।
इस प्रकार, इवेंट-ड्रिवेन प्रोग्रामिंग [3], डेटाफ्लो-प्रोग्रामिंग [4], स्ट्रीम प्रोसेसिंग [5] और कई अन्य प्रतिमानों का जन्म हुआ।
मैं इन प्रतिमानों पर अनुयायियों और विशेषज्ञों की आलोचना की एक धारा को जगाने का प्रयास करूँगा, उनके सामान्य सार को सरल शब्दों में व्यक्त करने की कोशिश करूँगा।
एक तरीका या दूसरा, ये प्रतिमान सूचना प्रवाह के साथ काम करते हैं। उसी समय, ईवेंट-चालित प्रोग्रामिंग, जैसा कि नाम से पता चलता है, सूचना प्रवाह तत्वों के उद्भव की प्रक्रिया पर ध्यान केंद्रित करता है, डेटाफ़्लो प्रोग्रामिंग - फ्लो कंट्रोल (विभाजन, विलय, धाराओं के परिवर्तन) और संसाधन के इष्टतम उपयोग पर स्ट्रीम प्रसंस्करण पर जब प्रसंस्करण प्रवाह होता है।
रिएक्टिव प्रोग्रामिंग एक ही चीज के बारे में है, लेकिन थ्रेड्स बनाने, प्रबंधन और उपयोग करने के विशिष्ट प्राथमिक कार्यों पर ध्यान केंद्रित करने के साथ। उन। आरपी वर्णन करता है कि आपका सिस्टम सूचना प्रवाह के तत्वों पर कैसे प्रतिक्रिया करता है (अंग्रेजी प्रतिक्रिया)। इस अर्थ में, रूसी में "अभिकर्मक प्रोग्रामिंग" (शब्द "प्रतिक्रिया") या "रिएक्शन प्रोग्रामिंग" (शब्द "कुछ प्रतिक्रिया" से) शब्द का उपयोग करना अधिक सही होगा यदि यह कान काटने के लिए नहीं था, और दूसरा गलत संगति का कारण नहीं बना।
मैं एक और देशद्रोही विचार व्यक्त करने के लिए उद्यम करूँगा। जिसे आज हम English Reactive Programming (प्रतिक्रियाशील प्रोग्रामिंग) कहते हैं। ऐतिहासिक कारणों से ऐसा कहा जाता है और इस बहुमत के पक्ष में झुकाव है।
इस प्रतिमान को अलग तरह से कहा जा सकता था। इसलिए, इसके वर्तमान नाम पर ध्यान केंद्रित न करें, लेकिन इसके सार को समझने की कोशिश करें।
और यद्यपि मैं आरपी के बारे में काफी सार स्तर पर बात करूंगा, मैं आरएक्सजेएस लाइब्रेरी एपीआई को ठोस उदाहरण के रूप में उद्धृत करूंगा।
RxJS का संक्षिप्त नाम जावास्क्रिप्ट के लिए प्रतिक्रियाशील विस्तार, प्रतिक्रियाशील प्रोग्रामिंग सुविधाओं के लिए एक जावास्क्रिप्ट विस्तार है। कई अन्य प्रोग्रामिंग भाषाओं के लिए समान एक्सटेंशन मौजूद हैं, जैसा कि नीचे दी गई तस्वीर में देखा जा सकता है, [6] से लिया गया है।
प्रतिक्रियाशील प्रोग्रामिंग एक्सटेंशन

आरपी के मेंटल मॉडल्स को आपके प्रोजेक्ट की आवश्यकता क्यों है

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

आश्चर्य, खतरे या आरपी में वह तरीका नहीं है जिससे हम सभी अभ्यस्त हैं

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

अंतर 1: एक कर्सर मॉडल के बजाय एक कम्प्यूटेशनल ग्राफ

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

1. 1 = 2
2. 2 = 3 
3. 3 = 1 + 2
4.  1, 2, 3
5. 1 = 4
6.  1, 2, 3

परिणाम देगा

2 3 5
4 3 5

हमारा कर्सर मानसिक मॉडल पूरी तरह से भविष्यवाणी करता है और इस तरह के परिणाम की व्याख्या करता है। तीसरी पंक्ति को संसाधित करने के बाद, मान X3 सेट है और पंक्ति 5 में निर्दिष्ट X1 के लिए नया मान इसे बदल नहीं सकता है।
आरपी की दुनिया में, "+" ऑपरेशन की व्याख्या के आधार पर, परिणाम सबसे अधिक संभावना होगा

2 3 5
4 3 7

इस दुनिया में, अधिकांश ऑपरेशन इनपुट मापदंडों को एक-दूसरे से जोड़ते हैं, जिससे कम्प्यूटेशनल ग्राफ़ बनते हैं जिसके माध्यम से गणना को "धक्का" दिया जाता है जब एक या अधिक पैरामीटर बदल दिए जाते हैं।

अंतर 2: अतुल्यकालिक संचालन

गणना के कर्सर मानसिक मॉडल के ढांचे में, अगला ऑपरेशन पिछले एक की तुलना में पहले शुरू नहीं हो सकता है।
निम्नलिखित उदाहरण पर विचार करें। मान लें कि फ़ंक्शन f1 उपयोगकर्ता पहचानकर्ता userId के मान से आधार वेतन की गणना करता है, और फ़ंक्शन f2 userId और वेतन के मूल्य के आधार पर बोनस की गणना करता है।
तब पूर्ण वेतन की गणना इस तरह दिख सकती है

1. X = f1(userId)
2. Y = f2(userId, X)
 X, Y

मान लीजिए कि किसी स्टाफ सदस्य का आधार वेतन 10,000 है। और 1000 इकाइयों का एक बोनस।
हमारा कर्सर मानसिक मॉडल आपको बताता है कि क्या प्रिंट करना है।

10000 1000

काश, अतुल्यकालिक आरपी की दुनिया में, संचालन की अवधि के आधार पर, परिणाम हो सकता है

(मैं अभी तक अपवाद नहीं मानता)।
बात यह है कि अतुल्यकालिक-प्रतिक्रियाशील दुनिया में, अगला ऑपरेशन पिछले एक के अंत की प्रतीक्षा नहीं करता है, अगर यह पिछले है) अतुल्यकालिक।
इसे समझने के लिए, आइए नीचे दिए गए चित्र में दिखाए गए यथार्थवादी उदाहरण का उपयोग करके कुछ महत्वपूर्ण विवरण देखें।
तस्वीर चार निर्देशों एल 1, एल 2, एल 3 और एल 4 के निष्पादन समय को दिखाती है जो एक दूसरे से स्वतंत्र हैं (उनकी संख्या हमारे लिए महत्वपूर्ण है, न कि वर्तनी) समकालिक (तस्वीर के ऊपरी भाग) और अतुल्यकालिक (तस्वीर के निचले हिस्से) मोड।

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

L1, L2, L3, l4

लेकिन अतुल्यकालिक में:

L3, L2, L1, L4

।

अंतर 3: अपूर्ण श्रृंखलाएं (उपभोक्ता के बिना) बिल्कुल काम नहीं करती हैं

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

„good“.split(„“).reverse().join(„“).replace(„oo“, „o“);

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

यह सब क्यों?

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

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

द स्पेस ऑफ मेंटल मॉडल्स प्रोग्रामिंग और इसमें एमएम आरपी का स्थान

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

	एकल मान और वस्तुएँ	, ,
		, (Stream)
	, (Promise)	(Workflow)

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

विस्तार क्या है?

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

कई जेट हो सकते हैं और हम उन्हें एक साथ मर्ज कर सकते हैं
जेट विषम हो सकते हैं
हम विभिन्न मानदंडों के अनुसार जेट्स को नए में विभाजित कर सकते हैं
हम एक धारा के ढांचे के भीतर उन्हें "बंद" और / या उन्हें नए रूप में बदल सकते हैं।

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

उनके जीवन चक्र की धाराएँ और चरण

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

प्रत्येक धागा किसी न किसी तरह उठता है
वह किसी तरह उपभोक्ता की ओर बढ़ रहा है।
उसके साथ रास्ते में कुछ होता है (वह बदल जाता है)
इसे कई धाराओं में विभाजित किया जा सकता है या अन्य धाराओं के साथ विलय किया जा सकता है
उपभोक्ता किसी तरह प्रवाह का उपयोग करता है, अस्तित्व को बंद करता है।

सूचीबद्ध पहलू प्रवाह के व्यक्तिगत तत्वों के जीवन चक्र के एक साथ चरण हैं।
आइए RxJS फ़ंक्शन के उदाहरण का उपयोग करके उन्हें और अधिक विस्तार से विचार करें।

धागा निर्माण

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

उपभोक्ता आंदोलन और प्रवाह परिवर्तन

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

"तीन-चरण प्रवाह"

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

विभाजन और विलय प्रवाह

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

धाराओं का उपयोग करना

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

धाराओं का खतरनाक आकर्षण

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

संक्षेप

इस लेख में मैंने आपको प्रतिक्रियात्मक प्रोग्रामिंग (एमएम आरपी) के मानसिक मॉडल के बारे में बताने की कोशिश की और आंशिक रूप से उन्हें आपकी चेतना में डाल दिया। आइए हम मुख्य बिंदुओं को फिर से दोहराएं।

एमएम आरपी विशेष हैं, पारंपरिक प्रोग्रामिंग के मानसिक मॉडल के समान नहीं हैं।
रिएक्टिव प्रोग्रामिंग पर शुरू करते समय, हमें याद रखना चाहिए कि एमएम के अन्य क्षेत्रों में कुछ अच्छी तरह से स्थापित हैं जैसे कि कर्सर, कॉल चेन या लूप काम नहीं करते हैं, या वे इस तरह काम नहीं करते हैं।
आरपी का मुख्य मानसिक मॉडल "सामान्य" तत्वों, त्रुटियों और धारा के अंत के बारे में जानकारी के लिए एक चैनल के साथ एक "तीन-चैनल स्ट्रीम" है।
धाराएँ परिमित और अनंत हो सकती हैं।
«», «» «» . «» «».
. (, ). .
, .
, .
. .
, «».

यदि आप इस विषय में रुचि रखते हैं, तो आप साइट [8] पर उपलब्ध सिमुलेटर का उपयोग करके धाराओं के साथ "खेल" कर सकते हैं।
यदि आप आरपी की अवधारणाओं को बेहतर ढंग से समझना चाहते हैं, तो मेरा सुझाव है कि आप पुस्तक [7] के माध्यम से काम करें, और निश्चित रूप से, रिएक्टिव मैनिफेस्टो [11] से परिचित हों।
आप प्रतिक्रियाशील प्रणालियों के डिजाइन और मॉडलिंग पर पुस्तकों [9] और [10] के माध्यम से काम करके अपने स्वयं के एमएम आरपी के गठन में अगले स्तर तक पहुंच जाएंगे।

साहित्य और संदर्भ

प्रोग्रामिंग विचारों का भौतिककरण है। (हब्र पर लेख। Habr.com/ru/post/425321 )
सिरोटिन वी। आरपीएसई: सॉफ्टवेयर इंजीनियरिंग के प्रतिमान के रूप में सुधार। arxiv.org/abs/1810.01904
घटना संचालित प्रोग्रामिंग। en.m.wikipedia.org/wiki/Event-driven_programming
Dataflow-programming. en.m.wikipedia.org/wiki/Dataflow_programming
Stream-processing. en.m.wikipedia.org/wiki/Stream_processing
Rx-Extensions: reactivex.io/languages.html
RxJS in Action. – 4. August 2017. Paul P. Daniels (Autor), Luis Atencio. Manning Publications. ISBN-13: 978-1617293412
RxJS online Documentstion. xgrommx.imtqy.com/rx-book/index.html
Reactive Design Patterns. 2017. Roland Kuhn Dr., Brian Hanafee, Jamie Allen. Manning Publications. ISBN-13: 978-1617291807
Functional and Reactive Domain Modeling. 2016. Debasish Ghosh.Manning Publications. ISBN-13: 978-1617292248
The Reactive Manifesto www.reactivemanifesto.org

: geralt

पर्यवेक्षकों के लिए मानसिक प्रतिक्रियाशील प्रोग्रामिंग मॉडल