🍙 👟 🏂🏽 खराब टीम के 9 विकल्प (डिजाइन पैटर्न) 📜 😓 😟

यह क्या है और क्यों है?

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

class CastSpellCommand extends Command { constructor (source, target, spell) { this.source = source; this.target = target; this.spell = spell; } execute () { const spellAbility = this.source.getAbility(SpellCastAbility); //      if (!cond) return error if (spellAbility == null) { throw new Error('NoSpellCastAbility'); } this.addChildren(new PayManaCommand(this.source, this.spell.manaCost)); this.addChildren(this.spell.getCommands(this.source, this.target)); //   : healthAbility.health = Math.max( 0, resultHealth ); } } // : async onMeleeHit (meleeHitCommand) { await view.drawMeleeHit( meleeHitCommand.source, meleeHitCommand.target ); } async onDealDamage (dealDamageCommand) { await view.showDamageNumbers( dealDamageCommand.target, dealDamageCommand.damage ); }

क्या किया जा सकता है?

एक अलग प्रकृति के कई दृष्टिकोणों पर विचार करें:

प्रेक्षक

 class Executor extends Observer {/* ... */} class Animator extends Observer {/* ... */}

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

 this.listeners.reduce((result, listener) => result && listener(action), true)

नुकसान: पर्यवेक्षकों को सही क्रम में घटनाओं की सदस्यता लेनी चाहिए।

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

जैसा है वैसा ही छोड़ दें

और वास्तव में। वर्तमान दृष्टिकोण के नुकसान और फायदे दोनों हैं:

कमांड चलाने की क्षमता का परीक्षण करने के लिए कमांड के निष्पादन की आवश्यकता होती है
एक बदलते क्रम में तर्क, शर्तें, विधि उपसर्ग हार्ड-वायर्ड हैं
लूप निर्भरताएं (कमांड <स्पेल <कमांड)
प्रत्येक क्रिया के लिए अतिरिक्त निकाय (विधि विधि, वर्ग और उसके निर्माता द्वारा प्रतिस्थापित किया जाता है)
एक व्यक्ति टीम के अत्यधिक ज्ञान और कार्य: खेल यांत्रिकी से सिंक्रनाइज़ेशन त्रुटियों और अन्य लोगों के गुणों के प्रत्यक्ष हेरफेर के लिए
इंटरफ़ेस भ्रामक है (न केवल कॉल को निष्पादित करता है, बल्कि AddChildren के माध्यम से कमांड भी जोड़ता है, जो स्पष्ट रूप से, विपरीत करता है)
प्रति आवश्यकता पुनरावर्ती निर्देशों की संदिग्ध आवश्यकता और कार्यान्वयन
प्रेषणकर्ता वर्ग, यदि कोई हो, अपने कार्य नहीं करता है
[+] कथित रूप से व्यवहार में चेतन करने का एकमात्र तरीका है, अगर एनिमेशन को पूरा डेटा चाहिए (मुख्य कारण के रूप में संकेत दिया गया है)
[+] संभवतः अन्य कारण

कुछ कमियों को अलग से निपटाया जा सकता है, लेकिन बाकी को अधिक कठोर परिवर्तनों की आवश्यकता होती है।

तदर्थ

टीम के निष्पादन के लिए शर्तें, विशेष रूप से खेल यांत्रिकी, को टीमों से बाहर ले जाना चाहिए और अलग से निष्पादित किया जाना चाहिए। स्थिति रनटाइम में बदल सकती है, और ग्रेग में निष्क्रिय बटन को हाइलाइट करने से पहले एनिमेशन शुरू होने पर काम करना होता है, तर्क का उल्लेख नहीं करना। नकल से बचने के लिए, यह क्षमता प्रोटोटाइप में सामान्य परिस्थितियों को संग्रहीत करने के लिए समझ में आ सकता है।
वापसी के तरीके, पिछले पैराग्राफ के संयोजन में, इस तरह के चेक की आवश्यकता गायब हो जाएगी:
```
 const spellAbility = this.source.getAbility(SpellCastAbility); //      if (!cond) return error if (spellAbility == null) { throw new Error('NoSpellCastAbility'); } 
```
जावास्क्रिप्ट इंजन ही सही टाइप-इयररोड दिखाएगा जब विधि को गलती से कहा जाता है।
टीम को भी इस तरह के ज्ञान की आवश्यकता नहीं है:
```
 healthAbility.health = Math.max( 0, resultHealth ); 
```
स्थानों को बदलने वाले तर्कों की समस्या को हल करने के लिए, उन्हें ऑब्जेक्ट द्वारा पारित किया जा सकता है।
यद्यपि कॉलिंग कोड अध्ययन के लिए उपलब्ध नहीं है, लेकिन ऐसा लगता है कि गेम की क्रियाओं के गैर-इष्टतम तरीके के कारण अधिकांश कमियां बढ़ती हैं। उदाहरण के लिए, बटन हैंडलर विशिष्ट संस्थाओं तक पहुंचते हैं। इसलिए, उन्हें विशिष्ट कमांड के साथ हैंडलर में प्रतिस्थापित करना काफी स्वाभाविक लगता है। यदि आपके पास डिस्पैचर है, तो कार्रवाई के बाद एनीमेशन को कॉल करना बहुत आसान है, आप उसी जानकारी को इसमें स्थानांतरित कर सकते हैं, इसलिए इसमें डेटा की कमी नहीं होगी।

बारी

कार्रवाई पूरी होने के बाद कार्रवाई के एनीमेशन को दिखाने के लिए, उन्हें कतार में जोड़ने और उन्हें समाधान 1 में लगभग चलाने के लिए पर्याप्त है।

 [ [ walkRequirements, walkAction, walkAnimation ], [ castRequirements, castAction, castAnimation ], // ... ]

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

अच्छी तरह से प्रोटोटाइप और डिबगिंग के लिए अनुकूल है।

दलित वर्ग

हम क्षमता के लिए एक एनीमेशन वर्ग बनाते हैं।

 class MovementAbility { walk (...args) { // action } } class AnimatedMovementAbility { walk (...args) { // animation } }

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

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

विधि संयोजन

 const AnimatedMovementAbility = combinedClass(MovementAbility, { ['*:before'] (method, ...args) { // call requirements }, ['*:after'] (method, ...args) { // call animations } })

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

प्रॉक्सी

हम प्रॉक्सी में क्षमताओं को लपेटते हैं, गेटर्स में तरीकों को पकड़ते हैं।

 new Proxy(new MovementAbility, {/* handler */})

नुकसान: कई बार नियमित कॉल की तुलना में धीमा, जो एनीमेशन के लिए इतना महत्वपूर्ण नहीं है। एक सर्वर पर जो लाखों वस्तुओं को संसाधित करता है, मंदी मंदी पर ध्यान देने योग्य होगी, लेकिन सर्वर को एनीमेशन की आवश्यकता नहीं है।

वादा

आप वादा से जंजीरों का निर्माण कर सकते हैं, लेकिन एक और विकल्प (ES2018) है:

 for await (const action of actionDispatcher.getActions()) { // }

getActions एक अतुल्यकालिक कार्रवाई पुनरावृत्ति देता है। पुनरावृत्ति की अगली विधि अगली कार्रवाई का आस्थगित वादा लौटाती है। उपयोगकर्ता और सर्वर से घटनाओं को संसाधित करने के बाद, हम समाधान () कहते हैं, एक नया वादा करते हैं।

बेहतर टीम है

इस तरह से ऑब्जेक्ट बनाएं:

 {actor, ability, method, options}

मापदंडों के साथ क्षमता विधि की जांच और कॉल करने के लिए कोड नीचे आता है। सबसे आसान और सबसे उत्पादक विकल्प।

टिप्पणी

नमूना आदेश स्रोत

खराब टीम के 9 विकल्प (डिजाइन पैटर्न)