👩‍🎨 👩‍💻 🍃 एफपी में डिजाइन और वास्तुकला। भाग २ 🤶🏽 🌀 😻

एफपी में अपस्ट्रीम डिजाइन। आइडिया अच्छे डिजाइन की नींव है। हास्केल में एंटीपार्टर्न।

सिद्धांत की बिट

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

यहां तीन संभावित उत्तर दिए गए हैं:

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

यह उत्तरार्द्ध से आता है कि सटीकता और पूर्णता (एस टेप्लाकोव, " ऑन डिजाइन ") का त्याग किए बिना, एक अच्छा डिजाइन 10 मिनट में समझाना आसान होना चाहिए।

ऊपर चित्र द्वारा चित्रित किया जा सकता है:

चार्ट: लक्ष्य-आवश्यकताएँ-सरलता

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

समस्या की स्थितियों के उदाहरण:

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

समस्या की स्थितियों का चार्ट

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

यह कहां से आता है? एक उदाहरण के रूप में UML का उपयोग करके एंड-टू-एंड मॉडलिंग प्रक्रिया को लें। डेवलपर आरेख की एक श्रृंखला के माध्यम से पता चलता है: मामलों का उपयोग करें → उपयोगकर्ता परिदृश्य → अनुक्रम आरेख → वस्तु आरेख → संचार आरेख → कक्षा आरेख →…। एक ही समय में, डोमेन शब्द कक्षाएं, मॉड्यूल, पैकेज और इंटरैक्शन बन जाते हैं (उदाहरण के लिए, इस या इस तरह )। लक्ष्य सरल है: उनके साथ सभी संस्थाओं और कार्यों की पहचान करना; यह है कि सिस्टम को विकसित करने के लिए "हेड-ऑन", जैसा कि हम इसे देखते और समझते हैं। हम सिस्टम के हमारे ज्ञान को इस प्रणाली के एक मॉडल में अनुवाद करते हैं, और हम पहले से यह नहीं कह सकते हैं कि कितने निकाय होंगे, कितने तत्व होंगे, और कनेक्शन के वेब क्या होंगे, यहां तक कि सामान्यीकरण के सभी प्रकारों को ध्यान में रखते हुए। उसी समय, डीएसएल को पेश करना बहुत मुश्किल है, क्योंकि डोमेन-विशिष्ट भाषा किसी भी आरेख से सीधे पालन नहीं करती है। क्या मॉडल सरल और पूर्ण होगा? अज्ञात।

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

हम इसे "अच्छे" डिजाइन की चौथी कसौटी पर कसते हैं:

4. मौलिक । अच्छा डिजाइन वह है जो सही विचार पर आधारित है, जो कि मौलिक स्तर पर विषय क्षेत्र का वर्णन करता है। दूसरे शब्दों में, "यह क्या है," नहीं "यह कैसे काम करता है।"

चार्ट: राइट आइडिया बेसिस ऑफ गुड डिजाइन है

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

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

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

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

थोडा अभ्यास

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

खेल की सामग्री के लिए क्या आवश्यकताएं थीं?

विस्तार: आप आसानी से खेल की दुनिया में वस्तुओं को जोड़ सकते हैं।
भिन्नता: वस्तुएं जटिल और सरल, सक्रिय और निष्क्रिय, महंगी और सस्ती, टिकाऊ और नाजुक हो सकती हैं।

इस मामले में, मैं वस्तुओं की परस्पर क्रिया में किसी प्रकार का बहुरूपता चाहूंगा। इसे कैसे लागू किया जा सकता है?

ललाट का हल। एंटीपैटर्न भगवान ADT

दिमाग में आया पहला विचार खेल की दुनिया में वस्तुओं के लिए एक एकल सार्वभौमिक बीजीय डेटा प्रकार बनाने और डेटामैट संरचना में इन वस्तुओं को रखने के लिए था। इस तरह:

मॉड्यूल GameLogic । प्रकार जहाँ
योग्य डेटा आयात करें । मानचित्र के रूप में एम
डेटा आइटम = Karyon ...
| प्लाज्मा ...
| माइटोकॉन्ड्रियन ...
| पत्थर ...

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

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

मॉड्यूल GameLogic । तर्क कहाँ
आयात GameLogic । प्रकार
stepWorld :: विश्व -> विश्व
लागू करें :: विश्व -> आइटम -> संचालितवर्ल्ड -> संचालितवर्ल्ड

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

w ( Karyon ... ) को लागू करें = ...
w ( प्लाज्मा ... ) को लागू करें = ...
w ( Mitochondrion ... ) उल्लू = लागू करें ...
...
getEnergy :: आइटम -> इंट
getEnergy ( Karyon e b c ) = e
getEnergy ( Mitochondrion e f g ) = e
getEnergy _ = त्रुटि "getEnergy असमर्थित है।"

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

हम अपनी आवश्यकताओं का विस्तार करेंगे:

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

खैर, अब आवश्यकताएं पहले से ही अधिक गंभीर दिख रही हैं। आइए इसे जानने की कोशिश करें।

एंटीपैटर्न "एग्ज़िस्टेंशियल टाइप क्लास"

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

- मॉड्यूल GameLogic.Karyon:
सक्रिय करें :: Karyon -> Point -> World -> OperatedWorld -> OperatedWorld
- मॉड्यूल GameLogic.Plasma:
सक्रिय करें :: प्लाज़्मा -> बिंदु -> विश्व -> परिचालित शब्द -> परिचालित शब्द

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

वर्ग सक्रिय मैं कहाँ
सक्रिय करें :: i -> बिंदु -> विश्व -> संचालितवर्ल्ड -> संचालितवर्ल्ड

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

टाइप वर्ल्ड = एम। नक्शा बिंदु ????

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

शुरू करने के लिए, हम हमारे लिए निम्नलिखित प्रकार के ब्याज बनाएंगे और उनके लिए सक्रिय कार्य को कार्यान्वित करेंगे।

मॉड्यूल GameLogic । प्लाज्मा जहां
डेटा प्लाज्मा = प्लाज्मा { प्लाज्माप्लेयर :: प्लेयर }
उदाहरण सक्रिय Karyon जहां
सक्रिय ( प्लाज्मा पीएल ) = अपरिभाषित

मॉड्यूल GameLogic । करयोन जहाँ
data Karyon = Karyon { karyonPlayer :: खिलाड़ी
, karyonEnergy :: ऊर्जा }
उदाहरण सक्रिय प्लाज्मा जहां
सक्रिय करें ( Karyon pl e ) = अपरिभाषित

अब आपको एक विषम विश्व मानचित्र बनाने की आवश्यकता है। ऐसा करने के लिए, एक अस्तित्वमान ActiveItem आवरण प्रकार परिभाषित करें, जो पहले से ही एक विश्व मानचित्र में संग्रहीत किया जा सकता है:

- मॉड्यूल GameLogic.Types:
{- # LANGUAGE अस्तित्ववादीकरण # -}
डेटा ActiveItem = forall i । सक्रिय i => MkActiveItem i
टाइप वर्ल्ड = एम। मानचित्र बिंदु ActiveItem
packItem :: सक्रिय i => i -> ActiveItem
packItem = MkActiveItem

ActiveItem प्रकार के बारे में मुझे कुछ भी पता नहीं है सिवाय इसके कि बाद के लिए सक्रिय प्रकार वर्ग का एक उदाहरण है। Karyon या Plasma जैसी किसी भी वस्तु को पैक करते समय, हम प्रकार की जानकारी खो देते हैं, लेकिन हम इसे किसी भी संग्रह में रख सकते हैं:

packKaryon = packItem ( Karyon 1 100 )
पैक्डप्लाज़्मा = पैक इटेम ( प्लाज्मा 1 )
दुनिया = एम। FromList [ ( प्वाइंट 1 1 1 , पैक्ड कैरियन )
, ( पॉइंट 1 1 2 , पैक्डप्लाज़्मा ) ]

अब आप मानचित्र वस्तुओं के माध्यम से जा सकते हैं और प्रत्येक सक्रिय संस्करण को कुछ इस तरह से कॉल कर सकते हैं:

stepWorld दुनिया = एम। foldrWithKey च एम। खाली दुनिया
जहाँ
f पॉइंट ( MkActiveItem i ) संचालित किया गया है। i = दुनिया को संचालित करता है

ActiveItem के लिए सक्रिय प्रकार वर्ग की एक आवृत्ति को परिभाषित करके आप प्रविष्टि को थोड़ा कम कर सकते हैं:

उदाहरण सक्रिय ActiveItem जहां
सक्रिय करें ( MkActiveItem i ) = i सक्रिय करें
...
stepWorld दुनिया = एम। foldrWithKey एम को सक्रिय करता है। खाली दुनिया
जहाँ
f पॉइंट i = सक्रिय i पॉइंट वर्ल्ड

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

लेट-फ़ंक्शंस और एंटीपैटर्न "ऑब्जेक्ट प्रकार"

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

द अमीबा वर्ल्ड का उदाहरण ( 3a0500a217 पर ):

छिपा हुआ पाठ

एक्टिवपाइग्रोइंग :: खिलाड़ी -> सीमा -> बिंदु -> दिशा -> ( विश्व , एनोटेशन , ऊर्जा ) -> ( विश्व , एनोटेशन , ऊर्जा )
एक्टिवपाइग्राउगिंग _ _ _ _ actRes @ ( w , anns , 0 ) = actRes
सक्रिय करेंप्राकृतिक प्लाइंग पी डायर ( w , एन्स , ई ) = केस बढ़ता हैप्लास्माफंक
बायाँ अंग -> ( w , anns ++ [ ann ] , e )
राइट ( w ', anns' ) -> ( w ', anns ++ anns' , e - 1 )
जहाँ
growPlasmaFunc = growPlasma pl bounds p dir w

सक्रिय करें :: बिंदु -> Karyon -> Shift -> ( विश्व , एनोटेशन , ऊर्जा ) -> ( विश्व , एनोटेशन , ऊर्जा )
सक्रिय करें _ _ ( KaryonFiller { } ) _ r = r
सक्रियपत्ती p k @ ( Karyon _ pl _ _ बाध्य ) sh सक्रियकडेटा | isCornerShift श = let
actFunc = activatePhewGrowing pl [ बाध्य p ] p ( सबडायरेक्शन 2 श )
। एक्टिवपाइरग्राउडिंग पीएल [ बाउंड पी ] पी ( सबडायरेक्शन 1 श )
actFunc सक्रियणडाटा में
सक्रिय करें pइस p @ @ ( Karyon _ pl _ _ बाध्य ) sh सक्रियकरणडेटा = दे
actFunc = activatePhewGrowing pl [ बाध्य p ] p ( दिशा श )
actFunc सक्रियणडाटा में

रीडर मोनड का उपयोग करके अपरिवर्तनीय डेटा को संदर्भ में लाकर कोड का भाग बेहतर बनाया जा सकता है, लेकिन इससे अनिवार्यता ( 8df9b7a224 कमिट नहीं ) होगी:

छिपा हुआ पाठ

सक्रिय करें :: सक्रियकरणडटा -> आर। रीडर सक्रियणकंटेक्ट सक्रियकरणडाटा
सक्रिय करें
isCornerPhew <- askIsCornerPiece
ifCornerPhew है तो सक्रिय करेंसामान्यवार्ता actData
और सक्रिय करें

एक्टिवपाइग्रोइंग :: दिशा -> एक्टिवेशनडाटा -> आर। रीडर सक्रियणकंटेक्ट सक्रियकरणडाटा
एक्टिवपाइग्राउज़िंग _ actData @ ( w , anns , 0 ) = return actData
एक्टिवपाइरग्राउडिंग dir actData @ ( w , anns , e ) = करते हैं
( पीएल , सीमाएं , पी ) <- आस्कलोकल्स
मामला बढ़ता
वाम वार्षिक -> वापसी ( डब्ल्यू , एन्स ++ + [ एएन ] , ई )
राइट ( w ', anns' ) -> रिटर्न ( w ', anns ++ एन्स' , e - 1 )
जहाँ
पूछनालोक = करना
( एक्टिवेशनकोटेक्स्ट के पी _ ) <- आर। पूछना
वापसी ( karyonPlayer k , [ karyonBound k p ] , p )

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

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

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

सिद्धांत की बिट

थोडा अभ्यास

More articles: