👃🏾 👰🏾 🐗 डेवलपर की सेवा में सरल राज्य मशीनें 👩🏻 🌹 🧚🏾

एक पल के लिए कल्पना कीजिए एक साधारण प्रोग्रामर की। मान लीजिए कि उसका नाम वास्या है और उसे वेबसाइट / डेस्कटॉप एप्लिकेशन / मोबाइल ऐप पर एक एनिमेटेड मेनू बनाना होगा। तुम्हें पता है, वे ऊपर से नीचे तक जाते हैं, जैसे विंडोज विंडो द्वारा मेनू या ओएस एक्स पर ऐप्पल के साथ मेनू। यहां यह है।

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

var opened = false;

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

 var opened = false; var animating = false; function onClick(event) { if (animating) return; if (opened) close(); else open(); }

कुछ समय बाद, वस्या को बताया जाता है कि मेनू को पूरी तरह से बंद और निष्क्रिय किया जा सकता है। कोई सवाल नहीं! हम यहां अनुभवी प्रोग्रामर हैं, हम सभी समझते हैं कि ... आपको ANOTHER ONE FLAG जोड़ना होगा! और, विकास के कुछ दिनों के बाद, मेनू कोड पहले से ही डबल-लाइन IFs से भरा है:

 if (enabled && opened && !animating && !selected && finishedTransition && !endOfTheWorld && ...) { ... }

वास्या सवाल पूछना शुरू करती हैं: यह कैसे हो सकता है कि एनिमेशन == सच और सक्षम == गलत; क्यों सब कुछ समय-समय पर छोटी गाड़ी है; आप यह भी कैसे समझ सकते हैं कि मेनू किस स्थिति में है? अहा! राज्यों ... उनके बारे में आगे और चर्चा की जाएगी।

इस वास्य से मिलो।

राज्य

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

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

आरेख से यह स्पष्ट है कि निष्क्रिय अवस्था से सक्रिय में केवल आरंभिक घटना से ही संभव है, और रुकी हुई स्थिति से सक्रिय और निष्क्रिय दोनों से मिलना संभव है। किसी कारण से, इस तरह की एक सरल अवधारणा को "Finite State Machine" या "Finite State Machine" कहा जाता है, जो आम लोगों के लिए बहुत डरावना है।

ओओपी वाचा के अनुसार, राज्यों को वस्तु के अंदर छिपा होना चाहिए और केवल बाहर से पहुंच योग्य नहीं होना चाहिए। उदाहरण के लिए, किसी ऑब्जेक्ट में ऑपरेशन के दौरान 20 अलग-अलग राज्य हो सकते हैं, लेकिन बाहरी एपीआई प्रश्न का उत्तर देता है "आप कैसे कर रहे हैं?" उत्तर " उनमें से कुछ भी नहीं" जैसे कि उनमें से 19 और केवल एक ही बार में शपथ लेता है कि सभी पॉलिमर विफल हो गए हैं ।

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

दुनिया की सबसे सरल राज्य मशीन

मान लीजिए कि अब वासा C # में एक परियोजना कर रहा है और उसे एक प्रकार की वस्तु के लिए एक साधारण राज्य मशीन की आवश्यकता है। वह कुछ इस तरह लिखते हैं:

 private enum State { Disabled, Idle, Animating } private State state; void setState(State value) { state = value; switch (state) { case State.Disabled: ... case State.Idle: ... case State.Animating : ... break; } }

और यह वर्तमान स्थिति के आधार पर घटनाओं को कैसे संसाधित करता है:

 void event1Handler() { switch (state) { case State.Idle: ... break; } }

लेकिन, यहां हम अनुभवी प्रोग्रामर हैं, हम सभी समझते हैं कि सेटस्टैट पद्धति अंततः दर्जनों पृष्ठों तक बढ़ेगी, जो (पाठ्यपुस्तकों में लिखा गया है) अच्छा नहीं है।

राज्य का पैटर्न

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

उदाहरण के लिए, स्टेट पैटर्न के लिए, आप IState इंटरफ़ेस बना सकते हैं:

 public interface IState { void Event1(); void Event2(); }

और प्रत्येक राज्य के लिए एक अलग वर्ग जो इस इंटरफ़ेस को लागू करता है। सिद्धांत रूप में, यह सुंदर और पाठ्यपुस्तक का 100% दिखता है।

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

भाषा आधारित कार्यान्वयन

कुछ प्रोग्रामिंग भाषाओं से कुछ समस्याओं को हल करना आसान हो जाता है। उदाहरण के लिए, रूबी में, सामान्य रूप से राज्य मशीन बनाने के लिए एक संपूर्ण डीएसएल (और एक नहीं) है। और C # में, एक राज्य मशीन को परावर्तन के माध्यम से सरल बनाया जा सकता है। कुछ इस तरह :

FiniteStateMachine वर्ग से विरासत में मिली ,
StateName_eventName () नामक विधियाँ बनाएँ, जिन्हें स्वचालित रूप से राज्य परिवर्तन और इवेंट प्रोसेसिंग पर कहा जाता है

लिखने के लिए वास्तव में बहुत कम कोड है।

ऊपर वर्णित प्रणाली को लागू करने के बाद, वासिया समझती है कि उसके पास प्लसस की तुलना में अधिक minuses हैं:

आपको FiniteStateMachine वर्ग से वारिस करने की आवश्यकता है,
कस्टम ईवेंट की प्रतिक्रियाओं में, आपको बड़े स्विच निर्माण लिखने की भी आवश्यकता होती है,
जब राज्य बदलता है तो मापदंडों को पारित करने का कोई तरीका नहीं है।

ढांचा

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

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

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

यहाँ, उदाहरण के लिए, स्टेटलेस फ्रेमवर्क द्वारा एक स्टेट मशीन का विवरण दिया गया है:

 var phoneCall = new StateMachine<State, Trigger>(State.OffHook); phoneCall.Configure(State.OffHook) .Permit(Trigger.CallDialed, State.Ringing); phoneCall.Configure(State.Ringing) .Permit(Trigger.HungUp, State.OffHook) .Permit(Trigger.CallConnected, State.Connected); phoneCall.Configure(State.Connected) .OnEntry(() => StartCallTimer()) .OnExit(() => StopCallTimer()) .Permit(Trigger.LeftMessage, State.OffHook) .Permit(Trigger.HungUp, State.OffHook) .Permit(Trigger.PlacedOnHold, State.OnHold);

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

एक्सएमएल

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

वास्या को यह भी विचार आया कि आप XML में सब कुछ कॉन्फ़िगर कर सकते हैं और कोड की एक पंक्ति को गलत नहीं करेंगे! परिणामस्वरूप, इसके ढांचे में अलग से लगभग निम्नलिखित सामग्री की XML फाइलें हैं:

 <fsm name="Vending Machine"> <states> <state name="start"> <transition input="nickel" next="five" /> <transition input="dime" next="ten" /> <transition input="quarter" next="start" action="dispense" /> </state> <state name="five"> <transition input="nickel" next="ten" /> <transition input="dime" next="fifteen" /> <transition input="quarter" next="start" action="dispense" /> </state> <state name="ten"> <transition input="nickel" next="fifteen" /> <transition input="dime" next="twenty" /> <transition input="quarter" next="start" action="dispense" /> </state> ... </states> </fsm>

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

समझौता

और फिर वासिया इस सब से थक गई और वह वापस दुनिया की सबसे सरल राज्य मशीन में वापस आ गई। उन्होंने इसे थोड़ा भुनाया और इसमें कोड लिखने के लिए नियम बनाए।

अद्यतन: टिप्पणियों के लिए धन्यवाद। यह वास्तव में एक छोटे से स्पष्टीकरण की कमी थी।

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

राज्य A पर स्विच करने के लिए, आपको StateA पद्धति पर कॉल करने की आवश्यकता है, जो आवश्यक लॉजिक को निष्पादित करेगा और setState (A) को कॉल करेगा। अपने आप को setState (A) कॉल करना अत्यधिक हतोत्साहित करता है।

यह निम्नलिखित निकला:

 /** *    enum   ,     enums. */ private enum State { Disabled, Idle, Animating } /** *    . ,         . */ private State state; /** *         state< >(). *                . *    setState(newValue)     . */ void stateDisabled() { switch (state) { case State.Idle: break; } setState(State.Disabled); // State Disabled enter logic } /** *       . * stateIdle(0); */ void stateIdle(int data) { setState(State.Idle); // State Idle enter logic } void stateAnimating() { setState(State.Animating); // State Animating enter logic } /** *  setState    * state = value; *   prevState = state;     . * ,         . */ void setState(State value) { switch ( state ) { case State.Animating: // state Animating exit logic break; // other states } state = value; } /** *     ,     . */ void event1Handler() { switch (state) { case State.Idle: // state Idle logic break; // other states } }

UPDATE: setState () में, किसी राज्य से बाहर निकलने के लिए एक अद्वितीय तर्क लिखा जाता है, और StateB () में राज्य ए को बाहर निकालने के लिए एक विशिष्ट तर्क संभव है, जब बी पर जाना संभव है, लेकिन इसका उपयोग बहुत कम किया जाता है।

राज्य मशीनों के लेखन के लिए एक साधारण सम्मेलन। यह काफी लचीला है और इसके निम्नलिखित फायदे हैं:

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

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

सभी समझौतों की तरह, कुछ कोड पहले एक ही स्थान पर हो सकते हैं, लेकिन फिर इसका एक अलग अर्थ होगा, या यह कहीं न कहीं नकल हो जाएगा। फिर हम इसे दूसरी जगह ले जा सकते हैं। हमें कोई मना नहीं करता। फिर भी, कोड को पत्थर से नहीं उकेरा गया है, यह सिर्फ पाठ है (डरावनी!) और परियोजना के विकास के साथ बदला जा सकता है।

अद्यतन: और setState () स्पष्टता के लिए पूरी तरह से एक सेटर के साथ प्रतिस्थापित किया जा सकता है।

निष्कर्ष

यह राज्य मशीनों की दुनिया में वासिया के आकर्षक साहसिक कार्य का समापन करता है। लेकिन अभी भी बहुत दिलचस्प है। एक अलग विषय केवल समानांतर और निर्भर राज्य मशीनों के लायक होगा।

मुझे उम्मीद है कि अगर आप अभी तक हर जगह राज्य मशीन का उपयोग नहीं कर रहे हैं, तो यह लेख आपको अच्छे की तरफ खींचेगा; यदि आप राज्य मशीनों के साथ काम करने के लिए अपना uberframework लिखते हैं, तो यह आपको नए सिरे से देखने में मदद करेगा।

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

डेवलपर की सेवा में सरल राज्य मशीनें