संशोधित रणनीति डिजाइन पैटर्न

Question

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

अनिवार्य रूप से, मेरे एल्गोरिदम के कुछ (लेकिन सभी नहीं), उन्हें एक अतिरिक्त पैरामीटर या दो की आवश्यकता है।

तो मुझे या तो करने की आवश्यकता होगी

• जब मैं उनकी गणना विधि लागू करता हूं, तो उन्हें एक अतिरिक्त पैरामीटर पास करें

या

• उन्हें SolidAl एल्गोरिथम वर्ग के अंदर चर के रूप में संग्रहीत करें, और एल्गोरिथ्म को कॉल करने से पहले उन्हें अपडेट करने में सक्षम हो।

क्या इस ज़रूरत के लिए कोई डिज़ाइन पैटर्न है / मैं रणनीति पैटर्न से चिपके रहते हुए इसे कैसे लागू कर सकता हूं?

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

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

Comments

C ++ में वैकल्पिक पैरामीटर कुछ भी हल नहीं करेंगे, क्योंकि वे कई अतिभारित तरीकों को परिभाषित करने के लिए सिर्फ एक आशुलिपि हैं।

— Maaartinus

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

— मारार्टिनस

Answer 1

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

उदाहरण के लिए

StrategyParameter //Base strategy parameter that most of the strategies need
        ^
        |
        |
SpecialStrategyParameter // will be used for strategies that need more parameter

और फिर, रणनीति पदानुक्रम को परिभाषित करें:

Interface MyStrategy {
   void myStrategyMethod(StrategyParameter parameter);
}

class MyNormalStrategy extends MyStrategy {
   void myStrategyMethod(StrategyParameter parameter) {
       //implement the logic here
   }
}

उपरोक्त रणनीति को इस रूप में कहें: myNormalStrategyInstance.myStrategyMethod(strategyParameter);

class MySpecializedStrategy extends MyStrategy {
   void myStrategyMethod(StrategyParameter parameter) {
       //implement the logic here
   }
}

SpecialStrategyParameterइसके बजाय उदाहरण से गुजरकर उपरोक्त रणनीति को कॉल करें :mySpecializedStrategy.myStrategyMethod(specialStrategyParameter);

कृपया अपडेट करें यदि कुछ स्पष्ट नहीं है। समझाने / स्पष्ट करने में खुशी होगी।

Comments

-1 को डाउनकास्ट की आवश्यकता होती है, डिजाइन के इनकैप्सुलेशन को तोड़ता है। हालांकि यह प्रश्न में डिजाइन पर एक सुधार है, इस बिल्ली की त्वचा के लिए बेहतर तरीके हैं।

— tallseth

@tallseth मैं डाउनकास्ट भी देखता हूं। लेकिन मुझे बेहतर तरीके नहीं दिखते। क्या आप बेहतर समाधान बता सकते हैं? एक लेख या कुछ और?

— नारेक

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

— 13

Answer 2

आपको अपनी रणनीति स्पष्ट करने की आवश्यकता है ।

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

मैंने पहले कॉन्फ़िगर करने योग्य रणनीतियों का उपयोग किया है , जहां आप निर्माण पर ठोस कक्षाओं का मानकीकरण करते हैं:

interface Strategy {
  int calculate();
}

class ConcreteStrategyThatNeedsAParameter implements Strategy {
  private final int param;
  public ConcreteStrategyThatNeedsAParameter(int param) {
    this.param = param;
  }
  public int calculate() { 
    // uses param...
  }
}

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

यह भी काम करता है यदि आपकी रणनीति विधि मापदंडों को लेती है, लेकिन तब आपका ग्राहक उन मापदंडों के बारे में जानता है और उन सभी कार्यान्वयनों के लिए उन्हें पास करता है जिनके साथ वह काम करता है।

Comments

क्लाइंट पैरामीटर प्रदान करने के लिए संदर्भ के साथ एक है।

— andyczerwonka

Answer 3

जब तक हस्ताक्षर इंटरफ़ेस पर स्पष्ट रूप से परिभाषित नहीं किया जाता है, तब भी यह रणनीति पैटर्न का अनुपालन करता है।

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

Answer 4

चोटी द्वारा प्रदान किए गए उपरोक्त उत्तर पर विस्तार - आप अमूर्त का उपयोग कर सकते हैं। मैं यहां चोटी के कोड का उपयोग कर रहा हूं -

इंटरफ़ेस MyStrategy { अमूर्त शून्य myStrategyMethod (StrategyParameter पैरामीटर); }

वर्ग MyNormalStrategy MyStrategy {सार्वजनिक ओवरराइड void myStrategyMethod (StrategyParameter पैरामीटर) को बढ़ाता है {// यहां तर्क को लागू करें}}

वर्ग MySpecializedStrategy MyStrategy {सार्वजनिक ओवरराइड myStrategyMethod (StrategyParameter पैरामीटर, ExtraStrategyParameter extraParameter) को बढ़ाता है {// यहां तर्क को लागू करें} }

यदि मैं आपके प्रश्न को सही ढंग से समझता हूं तो आप कुछ एल्गोरिदम में एक अतिरिक्त पैरामीटर पास करना चाहते थे? कृपया मुझे बताएं कि क्या यह वह है जिसे आप ढूंढ रहे थे?

Answer 5

यदि आप डिज़ाइन पैटर्न बुक को देखते हैं, तो यह गलत नहीं है कि कुछ SimpleStrategy मौजूद हैं जो पारित किए गए मापदंडों में से कम या कोई भी उपयोग नहीं करते हैं, या यह कि पैरामीटर एक आकार-फिट-सभी / सबसे कम-सामान्य गुणक हैं। यहां डिजाइन का विकल्प यह है कि क्या यह अतिरिक्त प्रसंस्करण के मामले में आपको नुकसान पहुंचाता है जो समाप्त नहीं होता है।