स्पेगेटी कोड के खिलाफ स्वचालित मशीनें

"मुझे स्पेगेटी पश्चिमी से प्यार है, मैं स्पेगेटी कोड से नफरत करता हूं"

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

• हम चर्चा करते हैं कि स्पेगेटी कोड इतना स्वादिष्ट क्यों नहीं है।
• कोड क्या वास्तव में करता है पर एक नया रूप का परिचय।
• हम फ़्रेम मशीन नोटेशन (FMN) पर चर्चा कर रहे हैं, जो डेवलपर्स को पेस्ट की एक गेंद को खोलने में मदद करता है।

हम सभी जानते हैं कि किसी और के कोड को पढ़ना कितना मुश्किल है। यह इस तथ्य के कारण हो सकता है कि कार्य स्वयं कठिन है या क्योंकि कोड की संरचना बहुत अधिक है ... "रचनात्मक"। अक्सर ये दोनों समस्याएं हाथ से चली जाती हैं।

चुनौतियां कठिन कार्य हैं, और आमतौर पर एक क्रांतिकारी खोज के अलावा कुछ भी नहीं है जो उन्हें सरल बना सकता है। हालाँकि, ऐसा होता है कि सॉफ़्टवेयर संरचना स्वयं अनावश्यक जटिलता जोड़ती है, और यह समस्या हल करने के लायक है ।

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


स्पेगेटी कोड के साथ स्थिति को स्पष्ट करने के लिए, हमें पहले इसे बदलने की जरूरत है:


खस्ता पास्ता

इसमें:


अल दांते!

चलो खाना बनाना शुरू करते हैं।

अव्यवस्थित अवस्था

पास्ता बनाने के लिए, हमें निश्चित रूप से खाना पकाने के लिए पानी की आवश्यकता होती है। हालांकि, यहां तक ​​कि स्पेगेटी कोड से जुड़े ऐसे प्रतीत होने वाले सरल तत्व बहुत भ्रामक हो सकते हैं।

यहाँ एक सरल उदाहरण है:

(temp < 32) 

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

अगर मैं वास्तव में पुष्टि करता हूं कि वह जाँचती है कि पानी सोलिड है या नहीं। लेन: फ़ारेनहाइट पैमाने के अनुसार, पानी +32 डिग्री पर जम जाता है] , तार्किक रूप से वापसी का क्या मतलब होगा?

 if (temp < 32) { // SOLID water } else { // not SOLID water. is (LIQUID | GAS) } 

हालाँकि चेक ने संख्याओं को दो समूहों में विभाजित किया है, वास्तव में तीन तार्किक अवस्थाएँ हैं - ठोस, तरल और गैस (SOLID, LIQUID, GAS)!

अर्थात्, यह संख्या रेखा:


हालत की जांच इस प्रकार से विभाजित करें:

 if (temp < 32) { 

 } else { 

 } 

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

यहाँ एक समान जाँच है:

 if (temp > 212) { // GAS water } else { // not GAS water. is (SOLID | LIQUID) } 

नेत्रहीन, यह इस तरह दिखेगा:

 if (temp > 212) { 

 } else { 

 } 

ध्यान दें:

1. संभव राज्यों का पूरा सेट कहीं भी घोषित नहीं किया गया है
2. सशर्त निर्माणों में कहीं भी तार्किक राज्य या घोषित राज्यों के समूह नहीं हैं
3. कुछ राज्यों को अप्रत्यक्ष रूप से सशर्त तर्क और शाखावार संरचना द्वारा वर्गीकृत किया गया है

इस तरह का कोड नाजुक है, लेकिन बहुत आम है, और इतना बड़ा नहीं है कि इसके समर्थन में समस्याएं पैदा करें। तो चलिए स्थिति को और बदतर बनाते हैं।


मुझे आपका कोड कभी भी पसंद नहीं आया

ऊपर दिखाए गए कोड से तात्पर्य पदार्थ के तीन अवस्थाओं - SOLID, LIQUID, GAS से है। हालांकि, वैज्ञानिक आंकड़ों के अनुसार, वास्तव में, चार अवलोकन योग्य राज्य हैं जिनमें प्लाज्मा (PLASMA) शामिल है (वास्तव में, कई अन्य हैं, लेकिन यह हमारे लिए पर्याप्त होगा)। यद्यपि कोई भी प्लाज्मा से एक पेस्ट तैयार नहीं कर रहा है, अगर यह कोड गितुब पर प्रकाशित किया गया है, और फिर उच्च ऊर्जा भौतिकी का अध्ययन करने वाले कुछ स्नातकोत्तर छात्र इसे कांटा करेंगे, हमें इस राज्य को भी बनाए रखना होगा।

हालांकि, जब प्लाज्मा जोड़ा जाता है, तो ऊपर दिखाया गया कोड निम्नलिखित को भली-भांति प्रदर्शित करेगा:

 if (temp < 32) { // SOLID water } else { // not SOLID water. is (LIQUID | GAS) + (PLASMA?) // how did PLASMA get in here?? } if (temp > 212) { // GAS water + (PLASMA) // again with the PLASMA!! } else { // not GAS water. is (SOLID | LIQUID) } 

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

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

हालांकि सशर्त डेटा जांच से पूरी तरह से छुटकारा पाने का कोई तरीका नहीं है, लेकिन उन्हें कम से कम करने वाली कोई भी तकनीक कोड जटिलता को कम करेगी।

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

सबसे पहले पानी को एक उबाल में लाएं ...

विज्ञान ने उन सभी संभावित संक्रमणों को नाम दिया जो तापमान में परिवर्तन होने पर एक पदार्थ बना सकते हैं।


हमारी कक्षा बहुत सरल है (और विशेष रूप से उपयोगी नहीं है)। यह राज्यों के बीच संक्रमण करने की चुनौतियों का जवाब देता है और वांछित लक्ष्य राज्य के लिए उपयुक्त होने तक तापमान में बदलाव करता है:

(नोट: मैंने यह छद्म संहिता लिखी है। इसे अपने काम में केवल अपने जोखिम और जोखिम पर उपयोग करें।)

 class WaterSample { temp:int Water(temp:int) { this.temp = temp } // gas -> solid func depose() { // If not in GAS state, throw an error if (temp < WATER_GAS_TEMP) throw new IllegalStateError() // do depose while (temp > WATER_SOLID_TEMP) decreaseTemp(1) } // gas -> liquid func condense() { // If not in GAS state, throw an error if (temp < WATER_GAS_TEMP) throw new IllegalStateError() // do condense while (temp > WATER_GAS_TEMP) decreaseTemp(1) } // liquid -> gas func vaporize() { // If not in LIQUID state, throw an error if (!(temp < WATER_GAS_TEMP && temp > WATER_SOLID_TEMP)) throw new IllegalStateError() // do vaporize while (temp < WATER_GAS_TEMP) increaseTemp(1) } // liquid -> solid func freeze() { // If not in LIQUID state, throw an error if (!(temp < WATER_GAS_TEMP && temp > WATER_SOLID_TEMP)) throw new IllegalStateError() // do freeze while (temp > WATER_SOLID_TEMP) decreaseTemp(1) } // solid -> liquid func melt() { // If not in SOLID state, throw an error if (temp > WATER_SOLID_TEMP) throw new IllegalStateError() // do melt while (temp < WATER_SOLID_TEMP) increaseTemp(1) } // solid -> gas func sublimate() { // If not in SOLID state, throw an error if (temp > WATER_SOLID_TEMP) throw new IllegalStateError() // do sublimate while (temp < WATER_GAS_TEMP) increaseTemp(1) } func getState():string { if (temp < WATER_SOLID_TEMP) return "SOLID" if (temp > WATER_GAS_TEMP) return "GAS" return "LIQUID" } } 

पहले उदाहरण की तुलना में, इस कोड में कुछ सुधार हैं। सबसे पहले, हार्ड-कोडेड "मैजिक" नंबर (32, 212) को राज्य के तापमान सीमाओं के स्थिरांक (WATER_SOLID_TEMP, WATER_GAS_TEMP) द्वारा प्रतिस्थापित किया जाता है। यह परिवर्तन राज्यों को अप्रत्यक्ष रूप से अधिक स्पष्ट करने के लिए शुरू होता है।

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

 // liquid -> solid if (!(temp < WATER_GAS_TEMP && temp > WATER_SOLID_TEMP)) throw new IllegalStateError() 

यह सशर्त जाँच निम्नलिखित करती है:

1. जाँच करता है कि temp जीएएस सीमा तापमान से कम है या नहीं
2. जाँच करता है कि temp ठोस सीमा से अधिक तापमान है
3. यदि इनमें से एक चेक सत्य नहीं है, तो त्रुटि देता है

यह तर्क भ्रामक है। सबसे पहले, एक तरल अवस्था में होने से निर्धारित होता है कि पदार्थ क्या नहीं है - एक ठोस या गैस।

 (temp < WATER_GAS_TEMP && temp > WATER_SOLID_TEMP) // is liquid? 

दूसरे, कोड यह देखने के लिए जांचता है कि क्या एक त्रुटि वापस करने की आवश्यकता है या नहीं यह पता लगाने के लिए पानी तरल है।

 !(temp < WATER_GAS_TEMP && temp > WATER_SOLID_TEMP) // Seriously? 

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

 bool isLiquidWater = (temp < WATER_GAS_TEMP && temp > WATER_SOLID_TEMP) if (!isLiquidWater) throw new IllegalStateError() 

इस कोड को समझना आसान है क्योंकि isLiquidWater स्थिति स्पष्ट है ।

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

फ़्रेम मशीन संकेतन

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

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

इस समस्या को हल करने के लिए, फ़्रेम एक मानकीकृत संकेतन प्रस्तुत करता है जो तीन एकीकृत स्तरों पर काम करता है:

1. सुरुचिपूर्ण और संक्षिप्त वाक्य रचना के साथ फ़्रेम नियंत्रकों को परिभाषित करने के लिए पाठ डीएसएल
2. मशीन के रूप में ऑब्जेक्ट-ओरिएंटेड कक्षाओं को लागू करने के लिए संदर्भ कोडिंग पैटर्न का एक सेट जिसे "नियंत्रक" कहते हैं।
3. दृश्य संकेतन जिसमें FMN का उपयोग जटिल परिचालनों को व्यक्त करने के लिए किया जाता है जो रेखांकन का प्रतिनिधित्व करने में मुश्किल होते हैं - फ़्रेम दृश्य संकेतन (FVNN)

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

फ़्रेम एक अंकन है जिसमें कई महत्वपूर्ण पहलू हैं:

1. FMN में ऑटोमेटा की अवधारणा से संबंधित प्रथम-स्तरीय वस्तुएं हैं, जो ऑब्जेक्ट-ओरिएंटेड भाषाओं में उपलब्ध नहीं हैं।
2. FMN विनिर्देश छद्म कोड में मानक कार्यान्वयन पैटर्न को परिभाषित करता है जो प्रदर्शित करता है कि FMN संकेतन कैसे लागू किया जा सकता है।
3. FMN जल्द ही किसी भी वस्तु-उन्मुख भाषा में संकलन (प्रगति में काम) कर सकेगा

नोट: संदर्भ कार्यान्वयन का उपयोग FMN संकेतन की पूर्ण समानता और किसी भी वस्तु-उन्मुख भाषा में इसे लागू करने का एक सरल तरीका प्रदर्शित करने के लिए किया जाता है। आप कोई भी तरीका चुन सकते हैं।

अब मैं आपको फ़्रेम - फ़्रेम इवेंट्स और फ़्रेम कंट्रोलर्स में दो सबसे महत्वपूर्ण प्रथम-स्तरीय वस्तुओं से परिचित कराऊंगा ।

फ्रेम इवेंट

FrameEvents FMN संकेतन की सादगी का एक अभिन्न अंग है। एक फ़्रेमवर्क को एक संरचना या वर्ग के रूप में लागू किया जाता है जिसमें कम से कम निम्नलिखित सदस्य चर होते हैं:

• संदेश आईडी
• शब्दकोश या पैरामीटर सूची
• वापसी वस्तु

यहाँ फ्रेमवेट क्लास का छद्म कोड है:

 class FrameEvent { var _msg:String var _params:Object var _return:Object FrameEvent(msg:String, params:Object = null) { _msg = msg _params = params } } 

फ़्रेम नोटेशन @ प्रतीक का उपयोग करता है, जो कि फ्रेमवेंट ऑब्जेक्ट की पहचान करता है। फ़्रेमवर्क की प्रत्येक आवश्यक विशेषता का उपयोग करने के लिए एक विशेष टोकन है:

 @|message| :  -    _msg @[param1] :  []      @^ :              _return 

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

 |buttonClick| // Select for a "buttonClick" event _msg [firstName] = "Mark" // Set firstName _params property to "Mark" ^ = "YES" // Set the _return object to "YES" 

इस तरह की एक धारणा पहली बार में अजीब लग सकती है, लेकिन जल्द ही हम देखेंगे कि कैसे घटनाओं के लिए इस तरह के एक सरल वाक्यविन्यास एफएमएन कोड की समझ को बहुत सरल करता है।

फ्रेम नियंत्रक

फ़्रेम नियंत्रक एक ऑब्जेक्ट-ओरिएंटेड क्लास है, जिसे फ़्रेम मशीन को लागू करने के लिए एक अच्छी तरह से परिभाषित तरीके से आदेश दिया गया है। नियंत्रक प्रकारों की पहचान # उपसर्ग द्वारा की जाती है:

 #MyController 

यह निम्नलिखित वस्तु उन्मुख pseudocode के बराबर है:

 class MyController {} 

जाहिर है कि यह वर्ग विशेष उपयोगी नहीं है। ताकि वह कुछ कर सके, घटनाओं पर प्रतिक्रिया देने के लिए नियंत्रक को कम से कम एक राज्य की आवश्यकता होती है।

नियंत्रक को इस तरह से संरचित किया जाता है, जिसमें विभिन्न प्रकार के ब्लॉक होते हैं, जिन्हें ब्लॉक नाम के आसपास के डैश द्वारा पहचाना जाता है:

 #MyController<br> -block 1- -block 2- -block 3- 

एक नियंत्रक में प्रत्येक ब्लॉक के एक से अधिक उदाहरण नहीं हो सकते हैं, और ब्लॉक प्रकारों में केवल कुछ प्रकार के उपकेंद्र हो सकते हैं। इस लेख में, हम केवल -machine- ब्लॉक की जांच करते हैं, जिसमें केवल राज्य हो सकते हैं। राज्य $ उपसर्ग टोकन द्वारा पहचाने जाते हैं।

यहां हम एक नियंत्रक के लिए FMN को देखते हैं जिसमें केवल एक राज्य के साथ मशीन है:

 #MyController // controller declaration -machine- // machine block $S1 // state declaration 

यहाँ ऊपर FMN कोड का कार्यान्वयन है:

 class MyController { // -machine- var _state(e:FrameEvent) = S1 // initialize state variable // to $S1 func S1(e:FrameEvent) { // state $S1 does nothing } } 

मशीन ब्लॉक के कार्यान्वयन में निम्नलिखित तत्व शामिल हैं:

1. _state वैरिएबल, जो वर्तमान स्थिति के एक फ़ंक्शन को संदर्भित करता है। इसे कंट्रोलर में पहले स्टेट फंक्शन के साथ इनिशियलाइज़ किया जाता है।
2. एक या एक से अधिक राज्य विधियाँ

फ़्रेम स्टेट विधि को निम्नलिखित हस्ताक्षर के साथ एक फ़ंक्शन के रूप में परिभाषित किया गया है:

 func MyState(e:FrameEvent); 

मशीन ब्लॉक के कार्यान्वयन के इन मूल सिद्धांतों को परिभाषित करने के बाद, हम देख सकते हैं कि फ्रेमवेट ऑब्जेक्ट मशीन के साथ कितनी अच्छी तरह से इंटरैक्ट करता है।

इंटरफ़ेस इकाई

फ़्रेमएवेन्ट्स की परस्पर क्रिया जो मशीन के संचालन को नियंत्रित करती है, फ्रेम नोटेशन की सादगी और शक्ति का बहुत सार है। हालांकि, हमने अभी तक इस सवाल का जवाब नहीं दिया है कि फ्रेमवाइव्स कहां से आते हैं - वे इसे नियंत्रित करने के लिए नियंत्रक में कैसे आते हैं? एक विकल्प: बाहरी ग्राहक स्वयं फ़्रेमएवेन्ट्स बना और आरंभ कर सकते हैं, और फिर सीधे _state सदस्य चर द्वारा बताई गई विधि को कॉल कर सकते हैं:

 myController._state(new FrameEvent("buttonClick")) 

एक बहुत ही बेहतर विकल्प एक सामान्य इंटरफ़ेस बनाना होगा जो _state सदस्य चर के लिए एक सीधा कॉल लपेटता है:

 myController.sendEvent(new FrameEvent("buttonClick")) 

हालाँकि, ऑब्जेक्ट-ओरिएंटेड सॉफ़्टवेयर बनाने के सामान्य तरीके के अनुरूप सबसे अधिक परेशानी मुक्त तरीका, सामान्य तरीकों का निर्माण करना है जो क्लाइंट की ओर से आंतरिक मशीन को एक घटना भेजते हैं:

 class MyController { func buttonClick() { FrameEvent e = new FrameEvent("buttonClick") _state(e) return e._return } } 

फ़्रेम एक इंटरफ़ेस ब्लॉक के लिए सिंटैक्स को परिभाषित करता है जिसमें ऐसी विधियाँ शामिल होती हैं जो कॉल को फ़्रेमवेट्स के लिए एक सामान्य इंटरफ़ेस में बदल देती हैं।

 #MyController -interface- buttonClick ... 

interface ब्लॉक में कई अन्य विशेषताएं हैं, लेकिन यह उदाहरण हमें एक सामान्य विचार देता है कि यह कैसे काम करता है। मैं श्रृंखला के निम्नलिखित लेखों में और स्पष्टीकरण दूंगा।

अब फ़्रेम ऑटोमेटन के संचालन का अध्ययन करना जारी रखें।

इवेंट हैंडलर

यद्यपि हमने दिखाया है कि कार को कैसे परिभाषित किया जाए, लेकिन हमारे पास अभी तक ऐसा कोई नोटेशन नहीं है जिसके साथ कुछ भी करना है। घटनाओं को संसाधित करने के लिए, हमें 1) उस घटना का चयन करने में सक्षम होना चाहिए जिसे संसाधित करने की आवश्यकता है और 2) इसे निष्पादित किए जा रहे व्यवहार से जोड़ने के लिए।

यहां एक सरल फ़्रेम नियंत्रक है जो घटनाओं को संभालने के लिए बुनियादी ढांचा प्रदान करता है:

 #MyController // controller declaration -machine- // machine block $S1 // state declaration |e1| ^ // e1 event handler and return 

जैसा कि ऊपर कहा गया है, _msg इवेंट के _msg विशेषता तक पहुंचने के लिए, FMN संकेतन ऊर्ध्वाधर लाइनों से कोष्ठक का उपयोग करता है:

 |messageName| 

एफएमएन भी रिटर्न स्टेटमेंट का प्रतिनिधित्व करने वाले एक एक्सपोर्टर टोकन का उपयोग करता है। ऊपर दिखाए गए नियंत्रक को निम्नानुसार लागू किया जाएगा:

 class MyController { // #MyController // -machine- var _state(e:FrameEvent) = S1 func S1(e:FrameEvent) { // $S1 if (e._msg == "e1") { // |e1| return // ^ } } } 

यहां हम देखते हैं कि एफएमएन संकेतन एक कार्यान्वयन पैटर्न से मेल खाता है जो समझने में आसान है और कोडिंग है।

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

एकल फोकस मशीनें

ऊपर हमने एक स्टेटलेस कंट्रोलर को देखा जो बहुत बेकार था।

 #MyController 

उपयोगिता की खाद्य श्रृंखला में एक कदम एक एकल राज्य के साथ एक वर्ग है, जो हालांकि बेकार नहीं है, बस उबाऊ है। लेकिन कम से कम वह कम से कम कुछ तो कर रहा है ।

पहले, देखते हैं कि केवल एक (निहित) राज्य के साथ एक वर्ग कैसे लागू किया जाएगा:

 class Mono { String status() { return "OFF" } } 

यहां कोई राज्य घोषित या निहित नहीं है, लेकिन मान लेते हैं कि यदि कोड कुछ करता है, तो सिस्टम "कार्यशील" स्थिति में है।

हम एक महत्वपूर्ण विचार भी पेश करेंगे: एक वस्तु को एक घटना भेजने के लिए इंटरफ़ेस कॉल के समान माना जाएगा। इसलिए, उपरोक्त कोड को प्रेषित करने की एक विधि के रूप में माना जा सकता है | स्थिति | मोनो क्लास, हमेशा $ वर्किंग स्टेट में।

इस स्थिति को घटना बंधन तालिका का उपयोग करके देखा जा सकता है:


अब आइए FMN को देखें, जो समान कार्यक्षमता को प्रदर्शित करता है और एक ही बाध्यकारी तालिका से मेल खाता है:

 #Mono -machine- $Working |status| ^("OFF") 

यहाँ यह है कि कार्यान्वयन कैसा दिखता है:

 class Mono { // #Mono // -machine- var _state(e:FrameEvent) = Working // initialize start state func Working(e:FrameEvent) { // $Working if (e._msg == "status") { // |status| e._return = "OFF" return // ^("OFF") } } } 

आप देख सकते हैं कि हमने रिटर्न स्टेटमेंट के लिए एक नई अधिसूचना भी पेश की है, जिसका अर्थ है कि अभिव्यक्ति का मूल्यांकन करना और परिणाम को इंटरफ़ेस में वापस करना:

 ^(return_expr) 

यह ऑपरेटर समकक्ष है

 @^ = return_expr 

या बस

 ^ = return_expr 

ये सभी ऑपरेटर कार्यात्मक रूप से समतुल्य हैं और आप इनमें से किसी का भी उपयोग कर सकते हैं, लेकिन ^(return_expr) सबसे अधिक अभिव्यंजक दिखता है।

स्टोव चालू करें

अब तक हमने 0 राज्यों के साथ एक नियंत्रक और 1 राज्य के साथ एक नियंत्रक देखा है। वे अभी तक बहुत उपयोगी नहीं हैं, लेकिन हम पहले से ही कुछ दिलचस्प के कगार पर हैं।

हमारे पास्ता को पकाने के लिए, आपको सबसे पहले स्टोव चालू करना होगा। निम्नलिखित एक एकल बूलियन चर के साथ एक सरल स्विच क्लास है:

 class Switch { boolean _isOn; func status() { if (_isOn) { return "ON"; } else { return "OFF"; } } } 

हालांकि पहली नज़र में यह स्पष्ट नहीं है, ऊपर दिखाया गया कोड ईवेंट बाइंडिंग की निम्न तालिका को लागू करता है:


तुलना के लिए, यहाँ एक ही व्यवहार के लिए एक FMN है:

 #Switch1 -machine- $Off |status| ^("OFF") $On |status| ^("ON") 

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

 class Switch1 { // #Switch1 // -machine- var _state(e:FrameEvent) = Off func Off(e:FrameEvent) { // $Off if (e._msg == "status") { // |status| e._return = "OFF" return // ^("OFF") } } func On(e:FrameEvent) { // $On if (e._msg == "status") { // |status| e._return = "ON" return // ^("ON") } } } 

तालिका आपको इसके विभिन्न राज्यों में नियंत्रक के उद्देश्य को जल्दी से समझने की अनुमति देती है। फ़्रेम अंकन संरचना और कार्यान्वयन पैटर्न दोनों के समान फायदे हैं।

हालांकि, हमारे स्विच में ध्यान देने योग्य कार्यात्मक समस्या है। यह राज्य में $ बंद से शुरू होता है, लेकिन राज्य पर $ स्विच नहीं कर सकता है! ऐसा करने के लिए, हमें एक राज्य परिवर्तन ऑपरेटर दर्ज करना होगा।

स्थिति बदलें

राज्य परिवर्तन कथन इस प्रकार है:

 ->> $NewState 

अब हम इस ऑपरेटर को $ Off और $ On के बीच स्विच करने के लिए उपयोग कर सकते हैं:

 #Switch2 -machine- $Off |toggle| ->> $On ^ |status| ^("OFF") $On |toggle| ->> $Off ^ |status| ^("ON") 

और यहाँ इसी घटना बाध्यकारी तालिका है:


नई घटना | टॉगल | अब दो राज्यों के माध्यम से एक परिवर्तन को ट्रिगर करता है। राज्य परिवर्तन संचालन कैसे लागू किया जा सकता है?

कहीं आसान नहीं है। यहाँ स्विच 2 का कार्यान्वयन है:

 class Switch2 { // #Switch2 // -machine- var _state(e:FrameEvent) = Off func Off(e:FrameEvent) { if (e._msg == "toggle") { // |toggle| _state = On // ->> $On return // ^ } if (e._msg == "status") { // |status| e._return = "OFF" return // ^("OFF") } } func On(e:FrameEvent) { if (e._msg == "toggle") { // |toggle| _state = Off // ->> $Off return // ^("OFF") } if (e._msg == "status") { // |status| e._return = "ON" return // ^("ON") } } } 

आप स्विच 2 में अंतिम सुधार भी कर सकते हैं ताकि यह न केवल आपको राज्यों के बीच स्विच करने की अनुमति दे, बल्कि राज्य को स्पष्ट रूप से सेट कर दे:

 #Switch3 -machine- $Off |turnOn| ->> $On ^ |toggle| ->> $On ^ |status| ^("OFF") $On |turnOff| ->> $Off ^ |toggle| ->> $Off ^ |status| ^("ON") 

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

 class Switch3 { // #Switch3 // -machine- var _state(e:FrameEvent) = Off /********************************** $Off |turnOn| ->> $On ^ |toggle| ->> $On ^ |status| ^("OFF") ***********************************/ func Off(e:FrameEvent) { if (e._msg == "turnOn") { // |turnOn| _state = On // ->> $On return // ^ } if (e._msg == "toggle") { // |toggle| _state = On // ->> $On return // ^ } if (e._msg == "status") { // |status| e._return = "OFF" return // ^("OFF") } } /********************************** $On |turnOff| ->> $Off ^ |toggle| ->> $Off ^ |status| ^("ON") ***********************************/ func On(e:FrameEvent) { if (e._msg == "turnOff") { // |turnOff| _state = Off // ->> $Off return // ^ } if (e._msg == "toggle") { // |toggle| _state = Off // ->> $Off return // ^ } if (e._msg == "status") { // |status| e._return = "ON" return // ^("ON") } } } 

हमारे स्विच के विकास में अंतिम चरण यह दर्शाता है कि एफएमएन नियंत्रक के उद्देश्य को समझना कितना आसान है। प्रासंगिक कोड दर्शाता है कि फ़्रेम तंत्र का उपयोग करना कितना आसान है।

स्विच मशीन बनाने के बाद, हम आग को चालू कर सकते हैं और खाना बनाना शुरू कर सकते हैं!

ध्वनि की अवस्था

एक कुंजी, यद्यपि सूक्ष्म, ऑटोमेटा का पहलू यह है कि मशीन की वर्तमान स्थिति या तो एक स्थिति (उदाहरण के लिए, चालू) या किसी प्रकार के डेटा या पर्यावरण के विश्लेषण का परिणाम है। जब मशीन वांछित स्थिति में बदल गई है, तो यह निहित है। कि कार के ज्ञान के बिना स्थिति नहीं बदलेगी।

हालांकि, यह धारणा हमेशा सच नहीं होती है। कुछ स्थितियों में, वर्तमान तार्किक स्थिति को निर्धारित करने के लिए डेटा का सत्यापन (या "संवेदन") आवश्यक है:

1. प्रारंभिक बहाल स्थिति - जब मशीन एक स्थिर स्थिति से बहाल हो जाती है
2. बाहरी स्थिति - "वास्तविक स्थिति" को परिभाषित करता है जो मशीन के निर्माण, बहाली या संचालन के समय पर्यावरण में मौजूद है
3. वाष्पशील आंतरिक स्थिति - जब एक रनिंग मशीन द्वारा प्रबंधित आंतरिक डेटा का हिस्सा मशीन के नियंत्रण से बाहर बदल सकता है

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

 $probeForState() 

हमारी स्थिति में, इस तरह की विधि को निम्नानुसार लागू किया जा सकता है:

 func probeForState():FrameState { if (temp < 32) return Solid if (temp < 212) return Liquid return Gas } 

जैसा कि हम देख सकते हैं, विधि केवल सही तार्किक स्थिति के अनुरूप राज्य फ़ंक्शन का संदर्भ देती है। इस संवेदन समारोह को फिर सही स्थिति में प्रवेश करने के लिए इस्तेमाल किया जा सकता है:

 ->> $probeForState() 

कार्यान्वयन तंत्र इस तरह दिखता है:

 _state = probeForState() 

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

व्यवहार विरासत और प्रेषण

व्यवहार विरासत और डिस्पैचर एक शक्तिशाली प्रोग्रामिंग प्रतिमान और इस लेख में फ़्रेम अंकन के बारे में अंतिम विषय है।

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

इसके लिए मेथड चेनिंग नामक तकनीक का उपयोग करके मशीनों को लागू किया जा सकता है । एक से दूसरे राज्य से घटनाओं स्थानांतरित करने के लिए FMN अंकन - यह प्रबंधक => :

 $S1 => $S2 

इस FMN कथन को निम्नानुसार लागू किया जा सकता है:

 func S1(e:FrameEvent) { S2(e) // $S1 => $S2 } 

अब हम देखते हैं कि राज्य के तरीकों को चेन करना कितना आसान है। आइए इस तकनीक को एक कठिन परिस्थिति में लागू करें:

 #Movement -machine- $Walking => $Moving |getSpeed| ^(3) |isStanding| ^(true) $Running => $Moving |getSpeed| ^(6) |isStanding| ^(true) $Crawling => $Moving |getSpeed| ^(.5) |isStanding| ^(false) $AtAttention => $Motionless |isStanding| ^(true) $LyingDown => $Motionless |isStanding| ^(false) $Moving |isMoving| ^(true) $Motionless |getSpeed| ^(0) |isMoving| ^(false) 

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


हमने जो तकनीक सीखी है, उसके लिए धन्यवाद, कार्यान्वयन बहुत सरल होगा:

 class Movement { // #Movement // -machine- /********************************** $Walking => $Moving |getSpeed| ^(3) |isStanding| ^(true) ***********************************/ func Walking(e:FrameEvent) { if (e._msg == "getSpeed") { e._return = 3 return } if (e._msg == "isStanding") { e._return = true return } Moving(e) // $Walking => $Moving } /********************************** $Running => $Moving |getSpeed| ^(6) |isStanding| ^(true) ***********************************/ func Running(e:FrameEvent) { if (e._msg == "getSpeed") { e._return = 6 return } if (e._msg == "isStanding") { e._return = true return } Moving(e) // $Running => $Moving } /********************************** $Crawling => $Moving |getSpeed| ^(.5) |isStanding| ^(false) ***********************************/ func Crawling(e:FrameEvent) { if (e._msg == "getSpeed") { e._return = .5 return } if (e._msg == "isStanding") { e._return = false return } Moving(e) // $Crawling => $Moving } /********************************** $AtAttention => $Motionless |isStanding| ^(true) ***********************************/ func AtAttention(e:FrameEvent) { if (e._msg == "isStanding") { e._return = true return } Motionless(e) // $AtAttention => $Motionless } /********************************** $LyingDown => $Motionless |isStanding| ^(false) ***********************************/ func LyingDown(e:FrameEvent) { if (e._msg == "isStanding") { e._return = false return } Motionless(e) // $AtAttention => $Motionless } /********************************** $Moving |isMoving| ^(true) ***********************************/ func Moving(e:FrameEvent) { if (e._msg == "isMoving") { e._return = true return } } /********************************** $Motionless |getSpeed| ^(0) |isMoving| ^(false) ***********************************/ func Motionless(e:FrameEvent) { if (e._msg == "getSpeed") { e._return = 0 return } if (e._msg == "isMoving") { e._return = false return } } } 

पानी की मशीन

अब हमारे पास FMN के बारे में ज्ञान की मूल बातें हैं, जो हमें यह समझने की अनुमति देती है कि राज्यों के साथ और अधिक बुद्धिमान तरीके से वाटरस्प्लम वर्ग को फिर से कैसे लागू किया जाए। हम अपने स्नातक छात्र भौतिक विज्ञानी के लिए भी इसे उपयोगी बनाएंगे और इसमें एक नया $ प्लाज़्मा राज्य जोड़ेंगे:


यहां पूर्ण FMN कार्यान्वयन कैसा दिखता है:

 #WaterSample -machine- $Begin |create| // set temp to the event param value setTemp(@[temp]) // probe for temp state and change to it ->> $probeForState() ^ $Solid => $Default |melt| doMelt() ->> $Liquid ^ |sublimate| doSublimate() ->> $Gas ^ |getState| ^("SOLID") $Liquid => $Default |freeze| doFreeze() ->> $Solid ^ |vaporize| doVaporize() ->> $Gas ^ |getState| ^("LIQUID") $Gas => $Default |condense| doCondense() ->> $Liquid ^ |depose| doDepose() ->> $Solid ^ |ionize| doIonize() ->> $Plasma ^ |getState| ^("GAS") $Plasma => $Default |recombine| doRecombine() ->> $Gas ^ |getState| ^("PLASMA") $Default |melt| throw new InvalidStateError() |sublimate| throw new InvalidStateError() |freeze| throw new InvalidStateError() |vaporize| throw new InvalidStateError() |condense| throw InvalidStateError() |depose| throw InvalidStateError() |ionize| throw InvalidStateError() |recombine| throw InvalidStateError() |getState| throw InvalidStateError() 

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

सभी भौतिक राज्य ($ ठोस, $ तरल, $ गैस, $ प्लाज्मा) $ डिफ़ॉल्ट राज्य से सुरक्षात्मक व्यवहार प्राप्त करते हैं। सभी घटनाएं जो वर्तमान स्थिति के लिए मान्य नहीं हैं, उन्हें $ Default राज्य में पारित कर दिया जाता है, जो एक InvalidStateError त्रुटि फेंकता है। यह दर्शाता है कि व्यवहार वंशानुक्रम का उपयोग करके कैसे सरल रक्षात्मक प्रोग्रामिंग को लागू किया जा सकता है।

और अब कार्यान्वयन:

 class WaterSample { // -machine- var _state(e:FrameEvent) = Begin /********************************** $Begin |create| // set temp to the event param value setTemp(@[temp]) // probe for temp state and change to it ->> $probeForState() ^ ***********************************/ func Begin(e:FrameEvent) { if (e._msg == "create") { setTemp(e["temp"]) _state = probeForState() return } } /********************************** $Solid => $Default |melt| doMelt() ->> $Liquid ^ |sublimate| doSublimate() ->> $Gas ^ |sublimate| ^("SOLID") ***********************************/ func Solid(e:FrameEvent) { if (e._msg == "melt") { doMelt() _state = Liquid return } if (e._msg == "sublimate") { doSublimate() _state = Gas return } if (e._msg == "getState") { e._return = "SOLID" return } Default(e) } /********************************** $Liquid => $Default |freeze| doFreeze() ->> $Solid ^ |vaporize| doVaporize() ->> $Gas ^ |getState| ^("LIQUID") ***********************************/ func Liquid(e:FrameEvent) { if (e._msg == "freeze") { doFreeze() _state = Solid return } if (e._msg == "vaporize") { doVaporize() _state = Gas return } if (e._msg == "getState") { e._return = "LIQUID" return } Default(e) } /********************************** $Gas => $Default |condense| doCondense() ->> $Liquid ^ |depose| doDepose() ->> $Solid ^ |ionize| doIonize() ->> $Plasma ^ |getState| ^("GAS") ***********************************/ func Gas(e:FrameEvent) { if (e._msg == "condense") { doCondense() _state = Liquid return } if (e._msg == "depose") { doDepose() _state = Solid return } if (e._msg == "ionize") { doIonize() _state = Plasma return } if (e._msg == "getState") { e._return = "GAS" return } Default(e) } /********************************** $Plasma => $Default |recombine| doRecombine() ->> $Gas ^ |getState| ^("PLASMA") ***********************************/ func Plasma(e:FrameEvent) { if (e._msg == "recombine") { doRecombine() _state = Gas return } if (e._msg == "getState") { e._return = "PLASMA" return } Default(e) } /********************************** $Default |melt| throw new InvalidStateError() |sublimate| throw new InvalidStateError() |freeze| throw new InvalidStateError() |vaporize| throw new InvalidStateError() |condense| throw InvalidStateError() |depose| throw InvalidStateError() |ionize| throw InvalidStateError() |recombine| throw InvalidStateError() |getState| throw InvalidStateError() ***********************************/ func Default(e:FrameEvent) { if (e._msg == "melt") { throw new InvalidStateError() } if (e._msg == "sublimate") { throw new InvalidStateError() } if (e._msg == "freeze") { throw new InvalidStateError() } if (e._msg == "vaporize") { throw new InvalidStateError() } if (e._msg == "condense") { throw new InvalidStateError() } if (e._msg == "depose") { throw new InvalidStateError() } if (e._msg == "ionize") { throw new InvalidStateError() } if (e._msg == "recombine") { throw new InvalidStateError() } if (e._msg == "getState") { throw new InvalidStateError() } } } 

निष्कर्ष

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


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