6

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

यहाँ एक उदाहरण (सादगी के लिए, मान लें कि केवल दो संभव एल्गोरिदम देखते हैं चलो)

class Foo 
{ 
private: 
    // At run-time the correct algorithm is used, e.g. a = new Algorithm1(1); 
    AlgorithmInterface* a; 

}; 

class AlgorithmInterface 
{ 
public: 
    virtual void DoSomething() = 0; 
}; 

class Algorithm1 : public AlgorithmInterface 
{ 
public: 
    Algorithm1(int i) : value(i) {} 
    virtual void DoSomething(){ // Does something with int value }; 
    int value; 
}; 

class Algorithm2 : public AlgorithmInterface 
{ 
public: 
    Algorithm2(bool b) : value(b) {} 
    virtual void DoSomething(){ // Do something with bool value }; 
    bool value; 
}; 
+5

कुछ पूर्व निर्धारित पैटर्न में अपने कोड को फिट करने की कोशिश करने के बजाय, बस इसे डिजाइन करें जो आपके लिए सबसे स्पष्ट है (और उम्मीद है कि हर किसी के लिए स्पष्ट हो) और बनाए रखने के लिए सबसे आसान है। दूसरे शब्दों में: डिजाइन पैटर्न चूसना। यदि * आपको * किसी समस्या को हल करने का एक शानदार तरीका मिल गया है, तो इसका उपयोग करें; चाहे वह कुछ मनमाने ढंग से डिजाइन पैटर्न का उल्लंघन करता है या नहीं, यह असंभव है। – GManNickG

+0

इसके अलावा, अगर आप हमें कुछ और देते हैं (ये पैरामीटर कैसे पास किए जा रहे हैं, आदि) हम आपको एक बेहतर उत्तर दे सकते हैं। लेकिन जैसा लगता है, मेरे लिए एक अच्छा समाधान दिखता है। – GManNickG

उत्तर

7

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

2

है ... मुझे लगता है कि यह सही है, अगर आप सभी मापदंडों आप की जरूरत है जब आप नई रणनीति बनाने और आप जो भी करते हैं वह कोड पढ़ने वाले सभी के लिए स्पष्ट है।

0

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

+1

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

+0

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

+0

@Eric, मुझे लगता है कि यह इस बात पर निर्भर करेगा कि क्या आप ग्राहकों को हमेशा एक ही कुंजी-> मूल्य जोड़े की आपूर्ति करने की अपेक्षा करते हैं। बेशक, यह सवाल पूछेगा कि कुंजी-> मूल्य जोड़े की आवश्यकता क्यों है। –

2

आप इस दृष्टिकोण के साथ सही हैं। हां यह रणनीति पैटर्न का सार है ... "कार्यान्वयन से स्वतंत्र एल्गोरिदम Vary।" आप ऑब्जेक्ट सरणी जैसे अपनी कक्षा को आरंभ करने के लिए आवश्यक पैरामीटर में पास करने के लिए खुद को एक सामान्य कन्स्ट्रक्टर दे सकते हैं।

आनंद लें!

1

रणनीति पैटर्न उपयोगी होते हैं जब आप रनटाइम पर निर्णय लेना चाहते हैं जो एल्गोरिदम का उपयोग किया जाना है।

0

आईएमएचओ, आप चुनौती का सामना कर रहे हैं क्योंकि आप कंक्रीट एल्गोरिदम के रचनात्मक पहलू और एल्गोरिदम के वास्तविक चलन के बीच उलझन में हैं। जब तक 'DoSomething' इंटरफ़ेस वही रहता है, Strategy Pattern का उपयोग किया जा सकता है। यह केवल अलग कंक्रीट एल्गोरिदम का निर्माण है जो आपके मामले में भिन्न होता है, जिसे Factory Method डिज़ाइन पैटर्न के माध्यम से संभाला जा सकता है।