सरल फैक्टरी बनाम फैक्टरी विधि: कारखाने बनाम क्लाइंट

Question

में स्विच स्टेटमेंट मैं समझता हूं कि सरल फैक्ट्री पर फैक्टरी विधि के मुख्य फायदों में से एक यह है कि यह ओपन-क्लोज़ेड सॉलिड सिद्धांत का उल्लंघन नहीं करता है। यही है, जब नए प्रकार जोड़े जाते हैं तो पूर्व को स्विच स्टेटमेंट को संशोधित करने की आवश्यकता नहीं होती है।

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

public class ObjectFactory { 
    public static IObject CreateObject(ObjectTypeEnum objectType) { 
     switch (objectType) { 
      case TypeA: 
       return ObjectA; 
       break; 
      case TypeB: 
       return ObjectB; 
       break; 
      case TypeC: 
       return ObjectC; 
       break; 
     } 
    } 
} 

और ग्राहक इस तरह यह कहेंगे:

IObject myObject = ObjectFactory.CreateObject(objectType); 

साहित्य में नुकसान यह है कि है जब नए ऑब्जेक्ट प्रकार जोड़े जाते हैं तो CreateObject को संशोधित करने की आवश्यकता होगी।

लेकिन फैक्टरी विधि के साथ, हम सिर्फ इस संशोधन कारखाने से ग्राहक को यह (क्लाइंट कोड) की तरह आगे बढ़ नहीं किया जाएगा,: इस मामले में

IObject myObject; 
switch (objectType) { 
      case TypeA: 
       myObject = ObjectAFactory.CreateObject(); 
       break; 
      case TypeB: 
       myObject = ObjectBFactory.CreateObject(); 
       break; 
      case TypeC: 
       myObject = ObjectCFactory.CreateObject(); 
       break; 
} 

ग्राहक संशोधित करने की आवश्यकता होगी हर बार एक नया प्रकार जोड़ा जाता है, पिछले मामले में बनाम कारखाने को संशोधित करने की आवश्यकता होगी। तो फिर एक दूसरे के ऊपर क्या लाभ है? कृपया इसे डुप्लिकेट के रूप में चिह्नित न करें, मैंने कारखानों के बारे में कई SO पोस्ट देखे हैं और कोई भी इस विशिष्ट भेद को संबोधित नहीं करता है।

क्या कोई बेहतर समाधान है जो क्लाइंट या फैक्ट्री पक्ष पर ओपन/क्लोज़ेड सिद्धांत का उल्लंघन नहीं करता है?

Answer 1

मानक Abstract Factory डिज़ाइन पैटर्न मदद नहीं करता है?
सरलीकृत जावा कोड:

public interface IFactory { 
    IObject createObject(); 
} 

public class FactoryA implements IFactory { 
    public IObject createObject() { 
     return new ObjectA(); 
    } 
} 

public class FactoryB implements IFactory { 
    public IObject createObject() { 
     return new ObjectB(); 
    } 
} 

Client is configured (injected) with the needed Factory at run-time 
    IFactory myFactory = ... // new FactoryA(); 
... 
IObject myObject = myFactory.createObject(); 
... 

भी देखें GOF डिजाइन पैटर्न मेमोरी/सार फैक्टरी http://w3sdesign.com पर।

वैरिएंट 2
enum ऑब्जेक्ट प्रकारों का उपयोग करने के बजाय, अपने ऑब्जेक्ट प्रकारों को पॉलिमॉर्फिज्म (स्विच कथन से बचने के लिए) परिभाषित करें। सरलीकृत जावा कोड:

public interface IObjectType { 
    int getObjectType(); 
    IObject createObject(); 
} 

public class ObjectTypeA implements IObjectType { 
    ... 
    public IObject createObject() { 
     return new ObjectA(); 
    } 
} 

public class ObjectTypeB implements IObjectType { 
    ... 
    public IObject createObject() { 
     return new ObjectB(); 
    } 
} 

Client determines object type 
IObjectType myObjectType = ... // new ObjectTypeA(); 
... 
IObject myObject = myObjectType.createObject(); 
... 

मेरा निष्कर्ष:
मुझे लगता है, एक बेहतर समाधान के बजाय enum Constans का उपयोग करने का बहुरूपता के साथ अपने प्रकार के डिजाइन करने के लिए किया जाएगा। यह स्विच स्टेटमेंट से बच जाएगा और क्लाइंट या फैक्ट्री साइड पर ओपन/क्लोज़ेड सिद्धांत का उल्लंघन नहीं करेगा।