फैक्टरी विधि पैटर्न खुले/बंद सिद्धांत का उल्लंघन करता है?

Question

क्या Factory Method pattern (फैक्टरी या सार फैक्टरी पैटर्न के साथ भ्रमित नहीं होना चाहिए) Open/Closed principle का उल्लंघन करता है?

अद्यतन: स्पष्टीकरण के लिए, मैं उस परिदृश्य का जिक्र कर रहा हूं जहां एक ठोस वर्ग पर स्थिर कारखाने के तरीके हैं। उदाहरण के लिए (इस एफएमपी पर विकिपीडिया पृष्ठ से है):

class Complex 
{ 
    public static Complex fromCartesian(double real, double imag) { 
     return new Complex(real, imag); 
    } 

    public static Complex fromPolar(double modulus, double angle) { 
     return new Complex(modulus * cos(angle), modulus * sin(angle)); 
    } 

    private Complex(double a, double b) { 
     //... 
    } 
} 

निजी निर्माता, subclassed किए जाने से वर्ग को नहीं रोकता है अर्थात बढ़ाया?

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

इन दोनों का उल्लंघन ओपन/बंद नहीं है?

Answer 1

नहीं, यह ओपन/क्लोज़ेड सिद्धांत का बिल्कुल उल्लंघन नहीं करता है।

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

फैक्टरी विधि पैटर्न निर्दिष्ट पैरामीटर के आधार पर एक अलग प्रकार का ऑब्जेक्ट बनाएगा। सही ढंग से किए जाने पर फैक्टरी विधि वास्तव में खुले/बंद सिद्धांत के साथ अच्छी तरह से काम करती है। हालांकि, यदि आप एक नई कक्षा बनाते हैं और फिर फैक्टरी विधि उस प्रकार की एक नई वस्तु बनाने के लिए चाहते हैं तो आपको फैक्टरी विधि बदलनी होगी।

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

Answer 2

नहीं। अपने विकिपीडिया लिंक से:

सॉफ्टवेयर संस्थाओं (वर्गों, मॉड्यूल, कार्यों, आदि) के विस्तार के लिए खुला होना चाहिए, लेकिन संशोधन

ओवरराइड कारखाने विधि विस्तार है के लिए बंद कर दिया। आप एक नई कक्षा बना रहे हैं। आप मौजूदा वर्ग को नहीं बदलते हैं। मूल के लिए उप-वर्ग को आपको प्रतिस्थापित करना होगा (आशा है कि आपके आईओसी कंटेनर की कॉन्फ़िगरेशन के माध्यम से)।

Answer 3

फैक्टरी पैटर्न स्वाभाविक रूप से OCP का उल्लंघन करने वाला नहीं है।

यह पर निर्भर करता है कि आप Complex का व्यवहार आगे लेते हैं।

तो ComplexComplex वस्तु के नए प्रकार के उत्पादन का समर्थन करने के लिए आवश्यक है, और आप नए fromX विधियां जोड़कर Complex संशोधित करने के लिए उन्हें समर्थन करने के लिए जोड़ रहे हैं चुनते हैं, तो इसका मतलब है कि ComplexOCP क्योंकि Complex चाहिए की एक उल्लंघन हो जाता है संशोधन के लिए फिर से खोला जा:

class Complex 
{ 
    public static Complex fromCartesian(double real, double imag) { 
     return new Complex(real, imag); 
    } 

    public static Complex fromPolar(double modulus, double angle) { 
     return new Complex(modulus * cos(angle), modulus * sin(angle)); 
    } 

    //class opened for modification 
    public static Complex fromOtherMeans(String x , String y) { 
     return new Complex(x, y); 
    } 
} 

आपको अपने आप को जावा वर्ग बदलने के लिए होने के दोषमुक्त करने के लिए किसी प्रकार की एक पाठ फ़ाइल या गुण फ़ाइल में नीचे इस समस्या को धक्का सकता है, लेकिन यह आप पर रोक नहीं लगाता ord में समाधान के इस क्षेत्र में अतिरिक्त तर्क लिखने से नए प्रकार के Complex का समर्थन करने के लिए एर।

आपके डिजाइन में Complex के उपयोग के आधार पर (विभिन्न प्रकार अलग कैसे हैं? आप उनका उपयोग कैसे कर रहे हैं?), कुछ वैकल्पिक विकल्प हैं जो अच्छी तरह से लागू हो सकते हैं।

ऐसे OCP अनुकूल विकल्प अतिरिक्त फैक्टरी विधियों को प्रदान करने के लिए Complex को उपclass करना है। एक सबक्लास सबसे सरल उदाहरण है कि कैसे Complex बढ़ाया गया है लेकिन संशोधित नहीं किया गया है।

इस मामले में Complex बदलने के लिए एक और OCP अनुकूल विकल्प Decorator pattern है। Complex के नए रूपों को बनाने की क्षमता के साथ निरंतर सजावट Complex ओसीपी का सम्मान करती है क्योंकि Complex संशोधित नहीं है लेकिन इसे नई कार्यक्षमता के साथ लपेटकर बढ़ाया गया है।

Complex की संरचना को बदलने के लिए एक तीसरा विकल्प हो सकता है ताकि इसकी गणना संरचना द्वारा आपूर्ति की जा सके। Complex के विभिन्न व्यवहारों के बीच अलग-अलग होने के लिए Strategy pattern का उपयोग करने का अवसर आपके सामने खुल जाएगा।

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

ऐसे मामलों में, बल्कि फैक्टरी पैटर्न SOLID सिद्धांतों का सम्मान करने के अपने कार्यान्वयन मोड़ करने की कोशिश कर की तुलना में, क्यों आप इसे सभी पर प्रयोग कर रहे हैं पर विचार करें।