एफपी में डिजाइन और वास्तुकला। भाग ३

गुण और कानून। परिदृश्य। हास्केल में नियंत्रण का उलटा।

थोड़ा बहुत सिद्धांत

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



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

प्रगति op = पुनरावृति ( `op` 2 )



ज्यामितीय रूपांतर , अंकगणितीयप्रक्रम :: पूर्णांक -> [ पूर्णांक ]

geometricProgression = प्रगति ( * )

अंकगणितप्रक्रिया = प्रगति ( + )



ज्यामितीय , अंकगणितीय :: [ पूर्णांक ]

geometricals = 10 $ geometricProgression 1 लें

अंकगणित = 10 $ अंकगणितीय अंक 1 लें

यहां, अन्य फ़ंक्शन ((*), (+), `op` 2) एक फ़ंक्शन (पुनरावृति, प्रगति) के इनपुट पर स्थानांतरित किए जाते हैं, अर्थात, कुछ कोड पेश किया जा रहा है। और प्राप्त फ़ंक्शन के अंदर, इस कोड को एक ब्लैक बॉक्स माना जाता है, जिसके लिए केवल प्रकार ज्ञात है। उदाहरण के मामले में, उदाहरण के लिए, दूसरा तर्क Integer -> Integer प्रकार का होना चाहिए, और इससे कोई फर्क नहीं पड़ता कि इसका उपकरण कितना जटिल है। इस प्रकार, नियंत्रण उलटा कार्यात्मक प्रोग्रामिंग का आधार है; सिद्धांत रूप में, उच्च-क्रम के कार्य आपको एक बड़े पैमाने पर एक बड़े अनुप्रयोग का निर्माण करने की अनुमति देते हैं। केवल एक ही समस्या है: IoC की यह व्याख्या बहुत भोली है, और यह निश्चित रूप से, भोली कोड के लिए है। पहले से ही उपरोक्त उदाहरण में, यह देखा जा सकता है कि कोड एक अखंड पिरामिड है, और एक वास्तविक अनुप्रयोग में यह विशाल अनुपात में बढ़ेगा और पूरी तरह से असमर्थित हो जाएगा।



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



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

बहुत अभ्यास

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



गुण और वस्तु



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

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

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



उदाहरण के लिए, हम मौखिक रूप से कुछ वास्तविक वस्तुओं का वर्णन करेंगे जो खेल के नक्शे पर हो सकते हैं:

कोर:

नाम = "केरोन"

स्थान = ( 1 , 1 , 1 )

परत = पृथ्वी

स्वामी = खिलाड़ी १

शक्ति = 100/100

बैटरी = 300/2000

कारखाना = प्लाज़्मा , खिलाड़ी १



प्लाज्मा:

नाम = "प्लाज्मा"

स्थान = ( 2 , 1 , 1 )

परत = पृथ्वी

स्वामी = खिलाड़ी १

ताकत = 30/40

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

- Object.hs:

डेटा प्रॉपर्टी = नामांकित नाम

| उपयुक्तता ( संसाधन स्थायित्व )

| PBattery ( संसाधन ऊर्जा )

| POwNERhip प्लेयर

| लेयर खेलते हैं

...

व्युत्पन्न ( दिखाएँ , पढ़ें , इक )

सार वस्तु के प्रकार को परिभाषित करें:

- Object.hs:

प्रकार PropertyKey = Int

प्रॉपर्टी मैप = M टाइप करें मैप प्रॉपर्टीके प्रॉपर्टी



डेटा ऑब्जेक्ट = ऑब्जेक्ट { propertyMap :: PropertyMap }

व्युत्पन्न ( दिखाएँ , पढ़ें , इक )

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



सबसे आसान तरीका गुणों की एक सूची को भरना है और इसे Data.Map में बदलना है :

- उद्देश्य:

आयात वस्तु



करियन = वस्तु $ एम। fromList [ ( 1 , PObjectId 1 )

, ( 4 , "नाम" "Karyon" )

, ( 2 , उपयुक्तता ( संसाधन 100 100 )

, ( 3 , PBattery ( संसाधन 300 2000 ) )

, ( 10 , पोर्वशिपशिप प्लेयर 1 )

, ( 5 , विधायिका ( बिंदु 1 1 1 ) )

, ... ]

... लेकिन रुकिए! किस तरह के तर्क से हम PObjectId, Dislocation और Ownership को लिखते हैं? सब के बाद, यह केवल मानचित्र पर वस्तुओं के लिए उनके बारे में बात करने के लिए समझ में आता है! दूसरी ओर, ऐसे सामान्य गुण हैं जो वस्तुओं के एक वर्ग को निर्दिष्ट करते हैं और फिर बदलते नहीं हैं: PNamed और PLayer, PFabric और PPassRestriction (आंदोलन निषेध)। Karyon में, परत केवल ग्राउंड हो सकती है, और PNamed "प्लाज्मा" गुण क्रमशः प्लाज्मा तक ही हो सकते हैं। यहां हमें इस समस्या का सामना करना पड़ता है कि वस्तुओं को सीधे मानचित्र पर रखा जाना चाहिए और उसी समय आपको प्रारंभिक डेटा के साथ टेम्पलेट की आवश्यकता होगी। टेम्पलेट्स के रूप में, तथाकथित " स्मार्ट कंस्ट्रक्टर " उपयुक्त हैं - फ़ंक्शन जो तैयार किए गए पैटर्न और इनपुट मापदंडों के एक छोटे सेट के अनुसार हमारे लिए एक तैयार-निर्मित वस्तु बनाएंगे। यहाँ क्या होशियार karyon फ़ंक्शन जैसा दिखता है:

- उद्देश्य:

आयात वस्तु



karyon pId प्लेयर पॉइंट = ऑब्जेक्ट $ M fromList [ ( 1 , PObjectId pId )

, ( 4 , "नाम" "Karyon" )

, ( 2 , उपयुक्तता ( संसाधन 100 100 )

, ( 3 , PBattery ( संसाधन 300 2000 ) )

, ( 10 , पोवेरशिप प्लेयर )

, ( 5 , विधान सभा बिंदु )

, ... ]

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

- वस्तुएं

प्लाज्माफैंग :: खिलाड़ी -> बिंदु -> कपड़ा

प्लाज्माफ्लिप pl p = makeObject $ do

एनर्जीकॉस्ट । = 1

योजना । = प्लाज्मा पीएल

निर्माण । = सत्य

प्लेसमेंटअल्ग । = placeToNearestEmptyCell



karyon :: खिलाड़ी -> बिंदु -> वस्तु

karyon pl p = makeObject $ do

nameA | = karyonName

परत | = जमीन

अव्यवस्था | = पी

बैटरीए | = ( 300 , जस्ट 2000 )

टिकाऊपन | = ( 100 , जस्ट 100 )

मालिकाना | = pl

फैब्रिक | = प्लाज़्माफायर प्लेन पी

कोड की समझ इस बात पर निर्भर करती है कि पाठक का ज्ञान और सोच लेखक के ज्ञान और सोच के साथ कितना मेल खाता है। क्या यह कोड स्पष्ट है? यह स्पष्ट है कि वह क्या करता है, लेकिन वह कैसे काम करता है? उदाहरण के लिए, ऑपरेटर क्या करते हैं "=।" और "= =" यहाँ मतलब है? MakeObject फ़ंक्शन कैसे काम करता है? कुछ नामों में अक्षर "A" क्यों होता है और कुछ में नहीं होता है? और वह सन्यासी है या कुछ और?



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

- Object.hs:

makeObject :: डिफ़ॉल्ट a => राज्य a ( ) -> a

makeObject = फ्लिप एग्जॉस्ट डिफ



data PAccessor a = PAccessor { कुंजी :: PropertyKey

, constr :: a -> संपत्ति }



- ऑपरेटर भरने के गुण:

( - = ) एक्सेसर v = करते हैं

सहारा <- मिलता है

let oldPropMap = _ propertyMap प्रॉप्स

let newPropMap = insertProperty ( कुंजी एक्सेसर ) ( constr accessor v ) पुरानेप्रोपपार्ट

$ सहारा लगाओ { _ propertyMap = newPropMap }



- नामांकित संपत्ति के लिए एक्सेसर:

isNamedValid ( नामांकित n ) = नहीं । null $ n

nameValidator एन | isNamedValid n = n

| अन्यथा = त्रुटि $ "अवैध नामित संपत्ति:" ++ शो एन



nameA = PAccessor 0 $ PNamed । namedValidator

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



वस्तुओं से संबंधित हमारा अंतिम प्रश्न है: विश्व डेटा प्रकार अब कैसा दिखता है? कोई महत्वपूर्ण परिवर्तन नहीं थे, दुनिया अभी भी एक प्रकार का मानचित्र है:

टाइप वर्ल्ड = एम। मानचित्र बिंदु वस्तु

Data.Map संरचना प्रदर्शन ग्रस्त है। एक अधिक उपयुक्त समाधान यहां दो-आयामी सरणी है; हास्केल में वेक्टर या रेपा जैसे कुशल वेक्टर कार्यान्वयन हैं। जब यह स्पष्ट हो जाता है कि खेल का प्रदर्शन पर्याप्त नहीं है, तो दुनिया के भंडार को लौटाना और उसकी समीक्षा करना संभव होगा, लेकिन अभी के लिए, विकास की गति अधिक महत्वपूर्ण है।



परिदृश्यों



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



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



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



हम स्क्रिप्टिंग सबसिस्टम के लिए आवश्यकताओं को रेखांकित करते हैं:

• विश्वसनीयता;
• संपत्ति अभिविन्यास;
• अनुक्रम;
• सादगी;
• स्क्रिप्ट विफल हो सकती है;
• प्रदर्शन;
• लिपियाँ अन्य लिपियाँ चला सकती हैं;
• ...

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

- परिदृश्य।

createProduct :: एनर्जी -> ऑब्जेक्ट -> एवल ऑब्जेक्ट

createProduct eCost sch = करते हैं

pl <- स्वामित्व पढ़ें

डी <- अव्यवस्था पढ़ें

प्रत्याहार pl eCost

वापसी $ समायोजित sch [ स्वामित्व । ~ pl , अव्यवस्था । ~ d ]



placeProduct ठेस plAlg = do

l <- withDefault ground $ getProperty परत ठेस

obj <- getActedObject

पी <- मूल्यांकनप्लसमेंटएएलजी प्लैग एल एलजे

$ वस्तु को बचाएं



च = करना

prodObj <- createProduct ( f ^। EnergyCost ) ( f ^। स्कीम )

स्थानउत्पाद prodObj ( f ^। प्लेसमेंटअल्ग )

वापसी "सफलतापूर्वक निर्मित।"



प्रोड्यूससेनारियो :: एवल स्ट्रिंग

उत्पादकसेनारियो = करते हैं

f <- फैब्रिक पढ़ें

अगर एफ ^। उत्पादन

फिर उत्पादन च

और वापसी "निर्माण रोका गया।"

लेखों की श्रृंखला के दूसरे भाग में, अर्थात् 'लेट-फ़ंक्शंस' में, हमने देखा कि कोड बोझिल और समझ से बाहर है। अब हम देखते हैं कि कोड हल्का है, अभी भी समझ से बाहर है, लेकिन एक निश्चित प्रणाली पहले से ही इसमें दिखाई दे रही है। आइए इसे जानने की कोशिश करें।



परिदृश्य डीआईओएस को दो भागों में विभाजित किया गया है: गेम डेटा और रनटाइम के लिए अनुरोध की भाषा। सब कुछ के दिल में एवल प्रकार है - या तो और राज्य के एक ढेर:

- मूल्यांकन।

EvalType ctx res = EitherT EvalError ( State ctx ) res टाइप करें

Eval Res = EvalType EvalationContext Res टाइप करें

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

data DataContext = DataContext { dataObjects :: Eval Objects

, dataOjectGraph :: Eval ( नेबरहुड्सफंक -> ऑब्जेक्टग्राफ )

, dataOjectAt :: Point -> Eval ( हो सकता है वस्तु ) }



data EvaluationContext = EvaluationContext { ctxData :: DataContext

, ctxTransactionMap :: TransactionMap

, ctxActedObject :: शायद वस्तु

, ctxNextRndNum :: Eval Int }

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



चूँकि एवल का कोई भी कार्य एक लिपि है, उनमें से प्रत्येक को चलाया और परखा जा सकता है। स्क्रिप्ट की व्याख्या सिर्फ मोनाड स्टैक का निष्पादन है:

- मूल्यांकन।

परिदृश्य का मूल्यांकन करें = evalState ( runEitherT परिदृश्य )

परिदृश्य निष्पादित करें = निष्पादित करें ( runEitherT परिदृश्य )

रन परिदृश्य = runState ( runEitherT परिदृश्य )

खेल परिदृश्यों के लिए, एक प्रवेश बिंदु है - सामान्यीकृत मेनसेनारियो फ़ंक्शन:

- परिदृश्य।

मेनसेनारियो :: Eval ( )

मेनसेनारियो = करते हैं

forProperty कपड़े का उत्पादनसेनारियो

forProperty मूविंग मूविंगसेकेनारियो

वापसी ( )



- कहीं मुख्य कोड में - पूरे खेल का एक टिक:

stepGame gameContext = runScenario mainScenario gameContext

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

मुख्य = करते हैं

Let ctx = testContext $ initialGame 1

परिणाम देना = निष्पादित करना ( प्लेसप्रोडक्ट ( प्लाज़्मा प्लेयर 1 पॉइंट 1 ) निकटतम इमेलसीसेल ) सीटीएक्स

प्रिंट परिणाम

अब हम परिदृश्य डीआईओएस रनटाइम की कुछ विशेषताओं से परिचित हो गए हैं, हम निम्नलिखित फ़ंक्शन तैयार कर रहे हैं:

प्रत्याहार pl pl cnt = do

obj <- SingleActual $ का नाम `is` karyonName ~ & ~ स्वामित्व` है` pl ~ & ~ बैटरीचार्ज `SuchThat` ( > = cnt )

batRes <- getProperty बैटरी obj

$ बैटरीचार्ज बचाएं । ~ संशोधित करें ।ResourceStock batRes $ obj

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

`` का नाम क्रियोननाम है

~ & ~ स्वामित्व `pl है

~ & ~ बैटरीचार्ज `ऐसे थॉट` ( > = सेंट )

यह अनुमान लगाना आसान है कि ऑपरेटर (~ & ~) का अर्थ है "और", और ऑपरेटर `एक मूल्य के लिए एक निश्चित संपत्ति की समानता निर्धारित करता है। तीसरी विधेय स्थिति केवल उन वस्तुओं का चयन करती है जिनके लिए बैटरी को वहां से अधिक ऊर्जा निकालने के लिए पर्याप्त चार्ज किया जाता है। बेशक, ऊर्जा समाप्त हो सकती है, और फिर ऑब्जेक्ट नहीं मिलेगा - इस मामले में, या तो मोनाड असफल-शाखा शुरू हो जाएगी, और पूरी स्क्रिप्ट रद्द कर दी जाएगी। लेकिन अगर ऊर्जा को वापस लिया जा सकता है, तो हम परिवर्तन वापस लेते हैं और जमा करते हैं:

$ बैटरीचार्ज बचाएं । ~ संशोधित करें ।ResourceStock batRes $ obj

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



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



Antipattern Lens + NoMonomorphismRestriction



सभी बीमारियों का कारण प्रॉपर्टी मैप डेटा प्रकार और गुणों के लिए लेंस में है:

संपत्ति kl = propertyMap । k पर । पगडंडी । एल



named = property ( key namedA ) _ named

durability = property ( key durabilityA ) _ durability

battery = property ( key batteryA ) _ battery

...

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



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

data Object = Object {

-- Properties:

objectId :: ObjectId -- static property

, objectType :: ObjectType -- predefined property



-- Runtime properties, resources:

, ownership :: Player -- runtime property... or can be effect!



, lifebound :: IntResource -- runtime property

, durability :: IntResource -- runtime property

, energy :: IntResource -- runtime property

}

कोई सिल्वर लाइनिंग नहीं है - संशोधन के परिणामस्वरूप, अन्य गुण बाहरी प्रभावों और कार्यों में बदल गए हैं। डिजाइन अधिक सही हो गया, हालांकि मुझे परिदृश्य डीआईओएस पर अधिकांश घटनाक्रमों को दूर करना पड़ा ...

एक निष्कर्ष के बजाय

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

नियंत्रण कार्यान्वयन का हास्केल उलटा

डिस्क्लेमर: लेखक के पास इस खंड के लिए शोध पूरा करने का समय नहीं था। भविष्य के लेखों में जारी रखने के लिए।



मोनाडिक राज्य इंजेक्शन



क्या है : निर्भरता इंजेक्शन।

इसका उपयोग किसके लिए किया जाता है : क्लाइंट कोड में बाहरी स्थिति के साथ अमूर्त कार्य के लिए।

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

संरचना :

हम संदर्भ डेटा प्रकार को परिभाषित करते हैं - इसमें राज्य के रूप में बाहरी स्थिति शामिल होगी:

data Context = Context { ctxNextId :: State Context Int }

. :

constantId :: State Context Int

constantId = return 42

:

nextId :: Int -> State Context Int

nextId prevId = do let nId = prevId + 1

modify ( \ctx -> ctx { ctxNextId = nextId nId } )

return nId

State:

client = do

externalId <- get >>= ctxNextId

doStuff externalId

return externalId

, :

print $ evalState client ( Context constantId )

print $ evalState client ( Context ( nextId 0 ) )

: gist

- :

Sequental ids:

[ ( 1 , "GNVOERK" ) , ( 2 , "RIKTIG YOGLA" ) ]

Random ids:

[ ( 59 , "GNVOERK" ) , ( 64 , "RIKTIG YOGLA" ) ]

मॉड्यूल अमूर्त



यह क्या है : एक ब्लैक बॉक्स।

इसका क्या उपयोग किया जाता है : क्रम में एल्गोरिथ्म के कार्यान्वयन का चयन करें।

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

पूरा उदाहरण : जिस्ट