फैक्टरी और रणनीति पैटर्न

Question

मुझे एक कक्षा बनाने की आवश्यकता है जो परिणाम सेट प्रोसेसिंग के लिए ज़िम्मेदार होगा लेकिन ऐसा हो सकता है कि परिणाम परिणाम को संसाधित करने के लिए अलग-अलग एल्गोरिदम का उपयोग किया जाना चाहिए।

मैं निम्नलिखित विकल्पों के बारे में पता कर रहा हूँ:

interface Strategy { 
    processResultSet(ResultSet rs); 
} 

class StrategyA implements Strategy { 
    processResultSet(ResultSet rs); 
} 

class StrategyB implements Strategy { 
    processResultSet(ResultSet rs); 
} 

प्रसंग वर्ग रणनीति और क्लाइंट के संदर्भ में शामिल होंगे बनाने की रणनीति के कार्यान्वयन से पारित करना चाहिए:

1) का प्रयोग करें रणनीति patern, नीचे छद्म कोड है प्रसंग वस्तु,

class Context { 
    private Strategy strategy; 

    public Context(Strategy strategy) { 
    this.strategy = strategy; 
    } 

    public doSomething(rs) { 
    strategy.processResultSet(rs); 
} 

समस्या

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

क्या यह रणनीति और फैक्ट्री का मिश्रण है या वास्तव में केवल फैक्टरी पैटर्न है?

Answer 1

यह निश्चित रूप से रणनीति और फैक्ट्री का संयोजन है - लेकिन मुझे नहीं लगता कि यह बुरा है। पैटर्न को एक दूसरे के साथ संयुक्त और उपयोग करने का इरादा है।

इस डिजाइन योजना को संदर्भ में देखना मुश्किल है कि यह एक अच्छा डिज़ाइन या खराब है या नहीं। आपके द्वारा यहां दी गई जानकारी के साथ यह किसी भी तरह से जा सकता है।

ऐसा लगता है कि आपका सिर सही जगह पर है, लेकिन मुझे आपको चेतावनी का एक शब्द दें: अपने ग्राहक को अपनी रणनीति से अलग करने के लिए बहुत कठिन मत बनो। मैंने अतीत में ऐसा किया है और यह एक गड़बड़ वाली गड़बड़ी का कारण बनता है जो कि मेरे कोड के दो हिस्सों के बीच थोड़ा सा कनेक्शन करने की अनुमति देता है। पृथक्करण अच्छा है, लेकिन सही अलगाव बनाए रखने के लिए संघर्ष करने से खराब कोड और सभी प्रकार की समस्याएं हो सकती हैं।

Answer 2

परिदृश्य में आप दर्शाते हैं कि वास्तव में एक संदर्भ की आवश्यकता नहीं होगी, जिसे इसके बजाय इच्छित फैक्ट्री द्वारा प्रतिस्थापित किया जाएगा। इस मामले में रणनीति पैटर्न सिर्फ ऊपर की ओर है और जटिलता की एक अनियंत्रित परत है। कार्यान्वयन को पुनः प्राप्त करने के लिए आपको बस एक इंटरफेस या अमूर्त वर्ग, कार्यान्वयन, और फैक्ट्री या प्रॉक्सी चाहिए।

Answer 3

हमने इसका उपयोग किया है यह कई अलग-अलग पार्सिंग परिदृश्य है और यह निश्चित रूप से काम करता है। मैंने इस बारे में एक कोड उदाहरण के साथ ब्लॉग किया है: http://www.herrodius.com/blog/136

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

Answer 4

Anny मेरे विचार से संबंधित टिप्पणियां:

1) वहाँ एक सेवा है - सिंगलटन। 2) इसमें डीएओ कक्षा का संदर्भ शामिल है - यह एक सिंगलटन भी है। 3) डीएओ में एक तरीका है जो परिणामसेट पुनर्प्राप्त करता है: ResultSet rs = ps.executeQuery(); मैं इस परिणाम सेट को संसाधित करने के लिए डीएओ के अंदर एक उपयुक्त रणनीति बनाना चाहता हूं। मैं इस रणनीति को डीएओ कन्स्ट्रक्टर में पास नहीं कर सकता क्योंकि यह इनकमिंग अनुरोध के लिए विशिष्ट है। इसे कन्स्ट्रक्टर में पास करने से यह सभी असामान्य अनुरोधों के लिए समान होगा। इसलिए मैंने डीएओ (डीएओ ऑब्जेक्ट इंस्टेंस) के अंदर एक फैक्ट्री बनाने का फैसला किया और एक विधि के अंदर मैं फैक्ट्री से उपयुक्त रणनीति (अनुरोध - स्थानीय ऑब्जेक्ट पर आधारित) बनाने और परिणामसेट को संसाधित करने के लिए इसका उपयोग करने जा रहा हूं।

क्या यह समाधान आपकी राय में अच्छा है?

Answer 5

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