एब्सट्रैक्ट फ़ैक्टरी और फ़ैक्टरी डिज़ाइन पैटर्न के बीच अंतर क्या हैं?

Question

मुझे पता है कि इन दोनों पैटर्न के बीच अंतर के बारे में कई पोस्ट हैं, लेकिन कुछ चीजें हैं जो मुझे नहीं मिल सकती हैं।

मैं जो पढ़ रहा हूं, उससे मैं देखता हूं कि फैक्टरी विधि पैटर्न आपको एक ही ठोस उत्पाद बनाने के तरीके को परिभाषित करने की अनुमति देता है लेकिन ग्राहक से कार्यान्वयन को छिपाता है क्योंकि वे एक सामान्य उत्पाद देखेंगे। मेरा पहला सवाल अमूर्त कारखाने के बारे में है। क्या इसकी भूमिका आपको ठोस वस्तुओं के परिवारों को बनाने की अनुमति देती है (जो केवल एक ठोस वस्तु के बजाय आप किस विशिष्ट कारखाने का उपयोग कर सकते हैं) पर निर्भर कर सकते हैं? क्या अमूर्त कारखाना केवल एक बहुत बड़ी वस्तु या कई वस्तुओं को वापस करता है जो आपको कॉल करने के तरीकों पर निर्भर करता है?

मेरे अंतिम दो प्रश्न एक एकल उद्धरण के बारे में हैं, जिन्हें मैं पूरी तरह से नहीं समझ सकता कि मैंने कई स्थानों पर देखा है:

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

मेरी समझ यह है कि फैक्ट्री मेथड पैटर्न में एक क्रिएटर इंटरफ़ेस होता है जो कि कंक्रीटक्रैक्टर को यह जानने के लिए प्रभारी बना देगा कि कौन सा कंक्रीटप्रोडक्ट झटपट बनाना है। क्या यह तात्कालिकता को संभालने के लिए विरासत का उपयोग करने का मतलब है?

अब उस उद्धरण के संबंध में, एब्सट्रैक्ट फैक्ट्री पैटर्न रचना के माध्यम से किसी अन्य वस्तु को वस्तु तात्कालिकता की जिम्मेदारी कैसे सौंपता है? इसका क्या मतलब है? ऐसा लग रहा है कि एब्सट्रैक्ट फैक्ट्री पैटर्न निर्माण प्रक्रिया का उपयोग मेरी आँखों में भी करने के लिए विरासत का उपयोग करता है, लेकिन फिर मैं अभी भी इन पैटर्नों के बारे में सीख रहा हूं।

विशेष रूप से अंतिम प्रश्न के साथ कोई मदद, बहुत सराहना की जाएगी।

Comments

के संभावित डुप्लिकेट क्या फैक्टरी और सार फैक्टरी पैटर्न के बीच मूल अंतर है?

— नवफाल

ग्राहक के दृष्टिकोण से "कैसे बनाया गया उदाहरण" देखकर, आपको उद्धरण को समझने में मदद मिलेगी।

— कार्तिक बोस

@ नवाफल, उस धागे में जवाब भयानक हैं।

— jaco0646

Answer 1

दोनों के बीच अंतर

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

क्योंकि फ़ैक्टरी विधि सिर्फ एक विधि है, यह एक उपवर्ग में ओवरराइड किया जा सकता है, इसलिए आपके उद्धरण का दूसरा भाग:

... फैक्ट्री मेथड पैटर्न वंशानुक्रम का उपयोग करता है और वांछित वस्तु तात्कालिकता को संभालने के लिए एक उपवर्ग पर निर्भर करता है।

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

अमूर्त कारखाना एक वस्तु है जिस पर कई कारखाने विधियाँ हैं। आपके उद्धरण के पहले भाग को देखते हुए:

... एब्सट्रैक्ट फ़ैक्टरी पैटर्न के साथ, एक वर्ग रचना के माध्यम से किसी वस्तु को वस्तु तात्कालिकता की जिम्मेदारी सौंपता है ...

वे क्या कह रहे हैं कि एक वस्तु ए है, जो फू वस्तु बनाना चाहता है। Foo ऑब्जेक्ट को स्वयं बनाने के बजाय (जैसे, फ़ैक्टरी विधि से), Foo ऑब्जेक्ट बनाने के लिए एक अलग ऑब्जेक्ट (अमूर्त फ़ैक्टरी) प्राप्त करने जा रहा है ।

कोड उदाहरण

आपको अंतर दिखाने के लिए, यहाँ एक कारखाने का उपयोग किया जाता है:

class A {
    public void doSomething() {
        Foo f = makeFoo();
        f.whatever();   
    }

    protected Foo makeFoo() {
        return new RegularFoo();
    }
}

class B extends A {
    protected Foo makeFoo() {
        //subclass is overriding the factory method 
        //to return something different
        return new SpecialFoo();
    }
}

और यहाँ उपयोग में एक सार कारखाना है:

class A {
    private Factory factory;

    public A(Factory factory) {
        this.factory = factory;
    }

    public void doSomething() {
        //The concrete class of "f" depends on the concrete class
        //of the factory passed into the constructor. If you provide a
        //different factory, you get a different Foo object.
        Foo f = factory.makeFoo();
        f.whatever();
    }
}

interface Factory {
    Foo makeFoo();
    Bar makeBar();
    Aycufcn makeAmbiguousYetCommonlyUsedFakeClassName();
}

//need to make concrete factories that implement the "Factory" interface here

Comments

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

— croraf

यकीन नहीं होता कि यह सही है। बहुत यकीन है कि फैक्ट्री मेथड फैक्ट्री विधियों के नाम पर एक डिजाइन पैटर्न है , लेकिन इसमें क्लास स्ट्रक्चर और इनहेरिटेंस शामिल है। यह एक एकल विधि नहीं है।

— अविव कोहन

तो क्या यह कहना सही है: फैक्टरी विधि विभिन्न उद्देश्यों के साथ सभी नियमित कक्षाओं में एक विधि हो सकती है। लेकिन एब्सट्रैक्ट फैक्ट्री एक क्लाइंट द्वारा उपयोग की जाने वाली एक क्लास / ऑब्जेक्ट है और केवल एक परिवार में कुछ उत्पाद बनाने के लिए जिम्मेदार है?

— हियु गुयेन

क्या "सुपर" में "सुपर" शब्द का उपयोग केवल फू के एक विशेष मामले का मतलब है, या वास्तव में इसका मतलब सुपर क्लास है? जैसा कि मैंने माना कि यह एक उपवर्ग होना चाहिए।

— दही

@dahui हाँ यह एक उपवर्ग है। मैंने इसे और SpecialFooअधिक स्पष्ट होने के लिए बदल दिया है ।

— बजे टॉम डॉलिंग सेप

Answer 2

एब्सट्रैक्ट फैक्ट्री एक बेस क्लास बनाती है जिसमें एब्सट्रैक्ट मेथड्स ऑब्जेक्ट्स के लिए डिफाइनिंग मेथड्स बनाए जाने चाहिए। प्रत्येक कारखाना वर्ग जो बेस क्लास प्राप्त करता है, प्रत्येक वस्तु प्रकार के अपने स्वयं के कार्यान्वयन का निर्माण कर सकता है।

फैक्टरी विधि सिर्फ एक साधारण विधि है जिसका उपयोग कक्षा में वस्तुओं को बनाने के लिए किया जाता है। यह आम तौर पर कुल रूट में जोड़ा जाता है ( Orderकक्षा में एक विधि है जिसे कहा जाता है CreateOrderLine)

सार कारखाना

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

interface IMessageQueueFactory
{
  IMessageQueue CreateOutboundQueue(string name);
  IMessageQueue CreateReplyQueue(string name);
}

public class AzureServiceBusQueueFactory : IMessageQueueFactory
{
      IMessageQueue CreateOutboundQueue(string name)
      {
           //init queue
           return new AzureMessageQueue(/*....*/);
      }

      IMessageQueue CreateReplyQueue(string name)
      {
           //init response queue
           return new AzureResponseMessageQueue(/*....*/);
      }

}

public class MsmqFactory : IMessageQueueFactory
{
      IMessageQueue CreateOutboundQueue(string name)
      {
           //init queue
           return new MsmqMessageQueue(/*....*/);
      }

      IMessageQueue CreateReplyQueue(string name)
      {
           //init response queue
           return new MsmqResponseMessageQueue(/*....*/);
      }
}

फैक्टरी विधि

HTTP सर्वर में समस्या यह है कि हमें हमेशा हर अनुरोध के लिए प्रतिक्रिया की आवश्यकता होती है।

public interface IHttpRequest
{
    // .. all other methods ..

    IHttpResponse CreateResponse(int httpStatusCode);
}

फ़ैक्टरी पद्धति के बिना, HTTP सर्वर उपयोगकर्ता (अर्थात प्रोग्रामर) कार्यान्वयन विशिष्ट वर्गों का उपयोग करने के लिए मजबूर होंगे जो IHttpRequestइंटरफ़ेस के उद्देश्य को पराजित करते हैं ।

इसलिए हम कारखाने की विधि का परिचय देते हैं ताकि प्रतिक्रिया वर्ग का निर्माण भी दूर हो।

सारांश

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

फैक्ट्री के तरीकों का उपयोग करते समय किसी को ध्यान रखना चाहिए क्योंकि ऑब्जेक्ट बनाते समय एलएसपी ( लिस्कोव सबस्टीट्यूशन सिद्धांत ) को तोड़ना आसान होता है ।

Comments

हमें एक ठोस उत्पाद की आवश्यकता क्यों है?

— एंड्रयू एस

क्योंकि कोई भी विचारों में निवेश नहीं करना चाहता है।

— jgauffin

एब्सट्रैक्ट फ़ैक्टरी को Button()"संबंधित उत्पादों के परिवार" बनाने के लिए बस से अधिक बनाना चाहिए । उदाहरण के लिए, विहित गोफ उदाहरण बनाता है ScrollBar()और Window()। फायदा यह है कि एब्सट्रैक्ट फैक्ट्री अपने कई उत्पादों में एक सामान्य विषय को लागू कर सकती है।

— jaco0646

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

— गठीला

@ प्रश्न: अपने प्रश्न का उत्तर देने के लिए। अगर हमें एक ही एब्सट्रैक्ट (इंटरफ़ेस) के लिए अलग-अलग ठोस उत्पाद (कक्षाएं) रखने की आवश्यकता नहीं है, तो हमें संभवतः कारखाने पैटर्न की आवश्यकता है न कि फ़ैक्टरी पैटर्न की। (कभी नहीं से बेहतर देर);)

— jgauffin

Answer 3

AbstractFactory और कारखाने डिजाइन पैटर्न के बीच अंतर इस प्रकार हैं:

• फैक्ट्री मेथड का उपयोग केवल एक उत्पाद बनाने के लिए किया जाता है, लेकिन एब्सट्रैक्ट फैक्ट्री संबंधित या आश्रित उत्पादों के परिवारों को बनाने के बारे में है।
• फ़ैक्टरी विधि पैटर्न ऑब्जेक्ट बनाने के लिए क्लाइंट के लिए एक विधि को उजागर करता है जबकि एब्सट्रैक्ट फ़ैक्टरी के मामले में वे संबंधित वस्तुओं के एक परिवार को उजागर करते हैं जो इन फैक्ट्री विधियों से मिलकर हो सकते हैं।
• फैक्ट्री मेथड पैटर्न एकल ऑब्जेक्ट के निर्माण को छुपाता है जबकि एब्सट्रैक्ट फैक्ट्री संबंधित वस्तुओं के परिवार के निर्माण को छुपाता है। अमूर्त कारखानों को आमतौर पर (कारखाने के) तरीकों का उपयोग करके लागू किया जाता है।
• एब्सट्रैक्ट फैक्ट्री पैटर्न किसी अन्य वर्ग के लिए ऑब्जेक्ट बनाने की जिम्मेदारी सौंपने के लिए कंपोजीशन का उपयोग करता है जबकि फैक्ट्री मेथड डिजाइन पैटर्न इनहेरिटेंस का उपयोग करता है और ऑब्जेक्ट बनाने के लिए एक व्युत्पन्न वर्ग या उपवर्ग पर निर्भर करता है।
• फैक्ट्री मेथड पैटर्न के पीछे का विचार यह है कि यह उस केस के लिए अनुमति देता है जहाँ एक क्लाइंट को यह पता नहीं होता है कि रनटाइम के दौरान इसे बनाने के लिए किन ठोस वर्गों की आवश्यकता होगी, लेकिन बस एक वर्ग प्राप्त करना चाहता है जो एब्सट्रैक्ट फैक्ट्री पैटर्न के दौरान काम करेगा। सबसे अच्छा उपयोग जब आपके सिस्टम को उत्पादों के कई परिवारों को बनाने के लिए होता है या आप कार्यान्वयन विवरणों को उजागर किए बिना उत्पादों का एक पुस्तकालय प्रदान करना चाहते हैं!

फैक्टरी विधि पैटर्न कार्यान्वयन:

सार फैक्टरी पैटर्न कार्यान्वयन:

Comments

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

— जोक्विन इराचुक

बुलेट पॉइंट सही हैं; हालाँकि, दोनों चित्र पूरी तरह से गलत हैं और बहुत भ्रामक हैं। सार फैक्टरी के एक सटीक मॉडल के लिए @ ट्राइ करने से नीचे का चित्र देखें।

— jaco0646

मैं सहमत हूँ 2 आरेख वास्तव में बहुत भ्रामक हैं। मैंने उन्हें ट्यूटोरियलस्पॉट वेबसाइट में देखा है और ईमानदार होने के लिए मैं उनसे 100% सहमत नहीं हूं। वर्णन हालांकि अच्छा लगता है

— SoftwareDeveloper

यह बहुत भ्रामक है।

— दि‍योदा_

50+ अपवोट और आरेख बहुत गलत हैं। प्रमाण आप SO पर कई डिज़ाइन पैटर्न के उत्तरों पर भरोसा नहीं कर सकते।

— फुहरमैनटर

Answer 4

एब्सट्रैक्ट फ़ैक्टरी और फ़ैक्टरी विधि के बीच मुख्य अंतर यह है कि एब्सट्रैक्ट फ़ैक्ट्री कंपोज़ द्वारा लागू की जाती है ; लेकिन फैक्टरी विधि विरासत द्वारा कार्यान्वित की जाती है ।

हां, आप इसे सही ढंग से पढ़ते हैं: इन दो पैटर्नों के बीच मुख्य अंतर पुरानी रचना बनाम वंशानुक्रम बहस है।

UML चित्र (GoF) पुस्तक में देखे जा सकते हैं। मैं कोड उदाहरण प्रदान करना चाहता हूं, क्योंकि मुझे लगता है कि इस धागे में शीर्ष दो उत्तरों से उदाहरणों को संयोजित करने से या तो जवाब देने से बेहतर प्रदर्शन होगा। इसके अतिरिक्त, मैंने कक्षा और विधि नामों में पुस्तक से शब्दावली का उपयोग किया है।

सार कारखाना

1. यहां समझ पाने के लिए सबसे महत्वपूर्ण बात यह है कि अमूर्त कारखाने को ग्राहक में इंजेक्ट किया जाता है। यही कारण है कि हम कहते हैं कि अमूर्त कारखाना संरचना द्वारा कार्यान्वित किया जाता है। अक्सर, एक निर्भरता इंजेक्शन फ्रेमवर्क उस कार्य को पूरा करेगा; लेकिन DI के लिए एक रूपरेखा की आवश्यकता नहीं है।
2. दूसरा महत्वपूर्ण बिंदु यह है कि यहाँ के कंक्रीट कारखाने फैक्ट्री मेथड इम्प्लीमेंटेशन नहीं हैं ! फ़ैक्टरी विधि के लिए उदाहरण कोड को नीचे दिखाया गया है।
3. और अंत में, नोट करने के लिए तीसरा बिंदु उत्पादों के बीच संबंध है: इस मामले में आउटबाउंड और उत्तर कतार। एक कंक्रीट फैक्ट्री एज़्योर कतारों का उत्पादन करती है, दूसरा एमएसएमक्यू का। GoF इस उत्पाद संबंध को एक "परिवार" के रूप में संदर्भित करता है और यह ध्यान रखना महत्वपूर्ण है कि इस मामले में परिवार का मतलब वर्ग पदानुक्रम नहीं है।

public class Client {
    private final AbstractFactory_MessageQueue factory;

    public Client(AbstractFactory_MessageQueue factory) {
        // The factory creates message queues either for Azure or MSMQ.
        // The client does not know which technology is used.
        this.factory = factory;
    }

    public void sendMessage() {
        //The client doesn't know whether the OutboundQueue is Azure or MSMQ.
        OutboundQueue out = factory.createProductA();
        out.sendMessage("Hello Abstract Factory!");
    }

    public String receiveMessage() {
        //The client doesn't know whether the ReplyQueue is Azure or MSMQ.
        ReplyQueue in = factory.createProductB();
        return in.receiveMessage();
    }
}

public interface AbstractFactory_MessageQueue {
    OutboundQueue createProductA();
    ReplyQueue createProductB();
}

public class ConcreteFactory_Azure implements AbstractFactory_MessageQueue {
    @Override
    public OutboundQueue createProductA() {
        return new AzureMessageQueue();
    }

    @Override
    public ReplyQueue createProductB() {
        return new AzureResponseMessageQueue();
    }
}

public class ConcreteFactory_Msmq implements AbstractFactory_MessageQueue {
    @Override
    public OutboundQueue createProductA() {
        return new MsmqMessageQueue();
    }

    @Override
    public ReplyQueue createProductB() {
        return new MsmqResponseMessageQueue();
    }
}

फैक्टरी विधि

1. यहाँ समझ का सबसे महत्वपूर्ण बिंदु यह ConcreteCreator है कि ग्राहक है। दूसरे शब्दों में, ग्राहक एक उपवर्ग है जिसका माता-पिता परिभाषित करता है factoryMethod()। यही कारण है कि हम कहते हैं कि फैक्टरी विधि विरासत द्वारा कार्यान्वित की जाती है।
2. दूसरा महत्वपूर्ण बिंदु यह याद रखना है कि फ़ैक्टरी विधि पैटर्न टेम्पलेट विधि पैटर्न की विशेषज्ञता से अधिक कुछ नहीं है। दो पैटर्न एक समान संरचना साझा करते हैं। वे केवल उद्देश्य में भिन्न होते हैं। फैक्ट्री मेथड क्रिएशनल है (यह कुछ बनाता है) जबकि टेम्प्लेट मेथड व्यवहारपूर्ण है (यह कुछ गणना करता है)।
3. और अंत में, ध्यान देने वाली तीसरी बात यह है कि Creator(माता-पिता) वर्ग अपना खुद का आक्रमण करता है factoryMethod()। यदि हम anOperation()मूल वर्ग से हटाते हैं , तो केवल एक विधि को पीछे छोड़ते हुए, यह अब फैक्टरी विधि पैटर्न नहीं है। दूसरे शब्दों में, फैक्टरी विधि को मूल वर्ग में दो से कम विधियों के साथ लागू नहीं किया जा सकता है; और दूसरे को आह्वान करना चाहिए।

public abstract class Creator {
    public void anOperation() {
        Product p = factoryMethod();
        p.whatever();
    }

    protected abstract Product factoryMethod();
}

public class ConcreteCreator extends Creator {
    @Override
    protected Product factoryMethod() {
        return new ConcreteProduct();
    }
}

विविध। और विविध फैक्टरी पैटर्न

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

हर फैक्ट्री पैटर्न को गोफ से एक से मेल खाने का अनुमान लगाने के चक्कर में न पड़ें।

Comments

अच्छे उदाहरणों के आधार पर शानदार और बहुत स्पष्ट जवाब, इस विषय में सबसे अच्छा आईएमओ।

— ल्यूक डूडा

महान व्याख्या। फैक्ट्री विधि के लिए +1 को अपने अमूर्त कारखाने विधि बिंदु को लागू करना चाहिए। इस बिंदु के साथ, इस बिंदु को समझे बिना, यह बहुत स्पष्ट है: अगर हमारे पास कारखाना विधि नहीं है, तो इसका तात्पर्य यह है कि इसका उपयोग किसी अन्य वर्ग द्वारा किया जाएगा, जो इसकी रचना करेगा और इसके उप वर्गों को इंजेक्ट किया जाएगा, यह अमूर्त कारखाने में बदल जाता है , अंतर कम स्पष्ट हो जाता है अगर यह इंगित करता है कि अमूर्त कारखाना विधि को कारखाने द्वारा खुद ही लागू किया जाना चाहिए जैसे कि टेम्पलेट विधि पैटर्न समझ में नहीं आता है

— nits.kk

एक और सवाल-टिप्पणी। factoryMethod()हमेशा protected "फ़ैक्टरी विधि" पैटर्न में विधि होनी चाहिए ? (मुझे लगता है कि हाँ)

— यारोस्लाव फेडोरुक

@YaroslavFedoruk, GoF पुस्तक publicकारखाने के तरीकों की अनुमति देती है , और विधि की आवश्यकता भी नहीं है abstract; लेकिन महत्वपूर्ण बिंदु यह है कि विधि वंशानुक्रम के लिए अभिप्रेत है, इसलिए यह (उदाहरण के लिए) staticया तो नहीं हो सकता है final। मैंने (आवश्यक) व्यापकता को उजागर करने के लिए विधि protectedऔर abstractयहाँ बनाया है ।

— jaco0646

@ nits.kk, आप संबंधित उत्तर में रुचि ले सकते हैं ।

— jaco0646

Answer 5

सार फैक्टरी संबंधित उत्पादों को बनाने के लिए एक इंटरफेस है, लेकिन फैक्टरी विधि केवल एक विधि है। सार फैक्ट्री को कई फैक्ट्री मेथड्स द्वारा लागू किया जा सकता है।

Comments

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

— जाक

Answer 6

आसान समझ के लिए इस उदाहरण पर विचार करें।

दूरसंचार कंपनियां क्या प्रदान करती हैं? उदाहरण के लिए ब्रॉडबैंड, फोन लाइन और मोबाइल, और आपको अपने उत्पादों को अपने ग्राहकों को पेश करने के लिए एक एप्लिकेशन बनाने के लिए कहा जाता है।

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

अब, कंपनी अपने ग्राहकों को अपने उत्पादों के एक बंडल यानी ब्रॉडबैंड, फोन लाइन और मोबाइल को पूरी तरह से पेश करना चाहती है, और यहां खेलने के लिए एब्सट्रैक्ट फैक्ट्री आती है ।

सार फैक्टरी , दूसरे शब्दों में, अन्य कारखानों की संरचना है जो अपने स्वयं के उत्पादों को बनाने के लिए जिम्मेदार हैं और सार फैक्टरी को पता है कि इन उत्पादों को अपनी स्वयं की जिम्मेदारियों के संबंध में अधिक सार्थक तरीके से कैसे रखा जाए।

इस मामले में, BundleFactoryएब्सट्रैक्ट फैक्ट्री है BroadbandFactory, PhonelineFactoryऔर MobileFactoryहैं Factory। अधिक सरल बनाने के लिए, इन फैक्ट्रियों में अलग-अलग उत्पादों को शुरू करने के लिए फैक्टरी विधि होगी ।

नीचे दिए गए कोड नमूने को देखें:

public class BroadbandFactory : IFactory {
    public static Broadband CreateStandardInstance() {
        // broadband product creation logic goes here
    }
}

public class PhonelineFactory : IFactory {
    public static Phoneline CreateStandardInstance() {
        // phoneline product creation logic goes here
    }
}

public class MobileFactory : IFactory {
    public static Mobile CreateStandardInstance() {
        // mobile product creation logic goes here
    }
}

public class BundleFactory : IAbstractFactory {

    public static Bundle CreateBundle() {
        broadband = BroadbandFactory.CreateStandardInstance();
        phoneline = PhonelineFactory.CreateStandardInstance();
        mobile = MobileFactory.CreateStandardInstance();

        applySomeDiscountOrWhatever(broadband, phoneline, mobile);
    }

    private static void applySomeDiscountOrWhatever(Broadband bb, Phoneline pl, Mobile m) {
        // some logic here
        // maybe manange some variables and invoke some other methods/services/etc.
    }
}

उम्मीद है की यह मदद करेगा।

Comments

staticGoF फ़ैक्टरी पैटर्न में या तो कोई विधियाँ नहीं हैं । ये गलत है।

— jaco0646

Answer 7

वास्तविक जीवन उदाहरण। (याद करने के लिए आसान)

फ़ैक्टरी

कल्पना कीजिए कि आप एक घर का निर्माण कर रहे हैं और आप एक दरवाजे के लिए बढ़ई के पास जाते हैं। आप दरवाजे और अपनी आवश्यकताओं के लिए माप देते हैं, और वह आपके लिए एक दरवाजे का निर्माण करेगा। इस मामले में, बढ़ई दरवाजे का एक कारखाना है। आपके विनिर्देश कारखाने के लिए इनपुट हैं, और दरवाजा कारखाने से उत्पादन या उत्पाद है।

सार कारखाना

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

मैंने यहाँ फैक्ट्री मेथड पैटर्न और एब्सट्रैक्ट फ़ैक्ट्री पैटर्न दोनों की शुरुआत की है, जो कि उन्हें समझाने वाले मुद्दों का उपयोग न करने और फिर उपरोक्त पैटर्न https://github.com/vikramnagineni/Design-Patterns/tree/master का उपयोग करके मुद्दों को हल करने के लिए है।

Answer 8

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

Answer 9

प्रेरणाओं में अंतर को समझें:

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

विचारों की इस पंक्ति में एक और पेचीदा प्रेरणा एक ऐसा मामला है जहां हर-या-पूरे समूह में से कोई भी ऑब्जेक्ट का एक संगत संस्करण नहीं होगा। कुछ स्थितियों के आधार पर, किसी भी प्रकार के वेरिएंट का उपयोग किया जाएगा और प्रत्येक मामले में सभी ऑब्जेक्ट एक ही प्रकार के होने चाहिए। यह समझने के लिए थोड़ा सा सहज हो सकता है क्योंकि हम अक्सर सोचते हैं कि - जब तक किसी वस्तु के वेरिएंट एक समान यूनिफ़ॉर्म कॉन्ट्रैक्ट ( व्यापक अर्थों में इंटरफ़ेस ) का पालन करते हैं, तब तक कंक्रीट कार्यान्वयन कोड कभी नहीं टूटना चाहिए। यहाँ दिलचस्प तथ्य यह है कि, यह हमेशा सच नहीं होता है, खासकर जब अपेक्षित व्यवहार को प्रोग्रामिंग अनुबंध द्वारा मॉडलिंग नहीं किया जा सकता है।

एक सरल ( GoF से विचार उधार लेना ) किसी भी GUI अनुप्रयोगों का कहना है कि एक आभासी मॉनिटर है जो एमएस या मैक या फेडोरा ओएस के लुक-ए-फील का अनुकरण करता है। यहाँ, उदाहरण के लिए, जब सभी विजेट ऑब्जेक्ट जैसे कि विंडो, बटन आदि में MS वैरिएंट होता है सिवाय एक स्क्रॉल-बार के जो मैक वेरिएंट से लिया जाता है, टूल का उद्देश्य बुरी तरह से विफल हो जाता है।

इन उपरोक्त मामलों से एब्सट्रैक्ट फैक्ट्री पैटर्न की मूलभूत आवश्यकता बनती है ।

दूसरी ओर, कल्पना करें कि आप एक रूपरेखा लिख ​​रहे हैं ताकि कई लोग आपके ढांचे का उपयोग करके विभिन्न उपकरण ( जैसे ऊपर दिए गए उदाहरणों में से एक ) का निर्माण कर सकें । किसी ढांचे के विचार से, आपको अपने तर्क में ठोस वस्तुओं का उपयोग नहीं करने की आवश्यकता नहीं है। आप विभिन्न वस्तुओं के बीच कुछ उच्च स्तरीय अनुबंध रखते हैं और वे किस प्रकार परस्पर क्रिया करते हैं। जब आप ( एक फ्रेमवर्क डेवलपर के रूप में ) बहुत सार स्तर पर रहते हैं, तो टूल के प्रत्येक बिल्डरों को आपके फ्रेमवर्क-कंस्ट्रक्शंस का पालन करने के लिए मजबूर किया जाता है। हालांकि, उन्हें ( टूल बिल्डरों को ) यह तय करने की स्वतंत्रता है कि किस वस्तु का निर्माण किया जाए और वे सभी वस्तुओं को कैसे बनाएंगे। पिछले मामले ( एब्सट्रैक्ट फ़ैक्टरी पैटर्न ) के विपरीत , आप ( फ्रेमवर्क निर्माता के रूप में )) इस मामले में ठोस वस्तुओं के साथ काम करने की आवश्यकता नहीं है; और बल्कि वस्तुओं के अनुबंध स्तर पर रह सकते हैं। इसके अलावा, पिछले प्रेरणाओं के दूसरे भाग के विपरीत, आपको या टूल-बिल्डरों को कभी भी वेरिएंट से ऑब्जेक्ट मिलाने की स्थिति नहीं आती है। यहां, जबकि फ्रेमवर्क कोड अनुबंध स्तर पर रहता है, प्रत्येक उपकरण-निर्माता अपने स्वयं के ऑब्जेक्ट का उपयोग करने के लिए प्रतिबंधित है ( मामले की प्रकृति से )। इस मामले में ऑब्जेक्ट क्रिएशन प्रत्येक कार्यान्वयनकर्ता और फ्रेमवर्क प्रदाताओं को सौंपे जाते हैं, जो केवल वस्तुओं को बनाने और वापस करने के लिए समान तरीके प्रदान करते हैं। फ्रेमवर्क डेवलपर को अपने कोड के साथ आगे बढ़ने के लिए इस तरह के तरीके अपरिहार्य हैं और इसका एक विशेष नाम है फैक्टरी विधि ( अंतर्निहित पैटर्न के लिए फैक्टरी विधि पैटर्न )।

कुछ नोट:

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

नमूना कोड:

//Part of framework-code
BoardGame {
    Board createBoard() //factory method. Default implementation can be provided as well
    Piece createPiece() //factory method

    startGame(){        //template method
         Board borad = createBoard()
         Piece piece = createPiece()
         initState(board, piece)
    }
}


//Part of Tool-builder code
Ludo inherits  BoardGame {
     Board createBoard(){ //overriding of factory method
         //Option A: return new LudoBoard() //Lodu knows object creation
         //Option B: return LudoFactory.createBoard() //Lodu asks AbstractFacory
     }
….
}

//Part of Tool-builder code
Chess inherits  BoardGame {
    Board createBoard(){ //overriding of factory method
        //return a Chess board
    }
    ….
}

Answer 10

1. मेरा पहला सवाल अमूर्त कारखाने के बारे में है। क्या इसकी भूमिका आपको ठोस वस्तुओं के परिवारों को बनाने की अनुमति देती है (जो केवल एक ठोस वस्तु के बजाय आप किस विशिष्ट कारखाने का उपयोग कर सकते हैं) पर निर्भर कर सकते हैं?

हाँ। एब्सट्रैक्ट फैक्ट्री का इरादा है:

संबंधित या आश्रित वस्तुओं के परिवारों को उनके ठोस वर्गों को निर्दिष्ट किए बिना बनाने के लिए एक इंटरफ़ेस प्रदान करें।

---

2. क्या अमूर्त कारखाना केवल एक बहुत बड़ी वस्तु या कई वस्तुओं को वापस करता है जो आपको कॉल करने के तरीकों पर निर्भर करता है?

आदर्श रूप में इसे एक वस्तु को वापस करना चाहिए जो ग्राहक द्वारा लागू किया जा रहा है।

3. मेरी समझ यह है कि फैक्ट्री मेथड पैटर्न में एक क्रिएटर इंटरफ़ेस होता है जो कि कंक्रीटक्रैक्टर को यह जानने के लिए प्रभारी बना देगा कि कौन सा कंक्रीटप्रोडक्ट झटपट बनाना है। क्या यह तात्कालिकता को संभालने के लिए विरासत का उपयोग करने का मतलब है?

हाँ। फैक्टरी विधि विरासत का उपयोग करती है।

4. एब्सट्रैक्ट फैक्ट्री पैटर्न किसी अन्य वस्तु को रचना के माध्यम से वस्तु तात्कालिकता की जिम्मेदारी सौंपता है? इसका क्या मतलब है?

AbstractFactory एक FactoryMethod को परिभाषित करता है और एक कंक्रीटप्रोडक्ट बनाने के लिए कंकरीट फैक्ट्री जिम्मेदार है। बस इस लेख में कोड उदाहरण के माध्यम से पालन करें ।

आप संबंधित एसई पदों में अधिक जानकारी पा सकते हैं:

फ़ैक्टरी और एब्सट्रैक्ट फ़ैक्टरी पैटर्न के बीच बुनियादी अंतर क्या है?

डिजाइन पैटर्न: फैक्टरी बनाम फैक्टरी विधि बनाम सार फैक्टरी

Answer 11

फैक्ट्री मेथड इनहेरिटेंस पर निर्भर करता है: ऑब्जेक्ट क्रिएशन उपवर्गों को सौंपा जाता है, जो ऑब्जेक्ट बनाने के लिए फैक्ट्री मेथड को लागू करते हैं।

एब्सट्रैक्ट फैक्ट्री ऑब्जेक्ट कंपोजीशन पर निर्भर करती है: फैक्ट क्रिएशन को फैक्ट्री इंटरफेस में उजागर तरीकों से लागू किया जाता है।

कारखाने और सार कारखाने पैटर्न के उच्च स्तर आरेख,

फैक्टरी विधि के बारे में अधिक जानकारी के लिए, इस लेख को देखें ।

एब्सट्रैक्ट फ़ैक्टरी विधि के बारे में अधिक जानकारी के लिए, इस लेख को देखें ।

Answer 12

न्यूनतम इंटरफ़ेस के साथ इसे बहुत सरल बनाने के लिए और कृपया "// 1" पर ध्यान दें:

class FactoryProgram
    {
        static void Main()
        {
            object myType = Program.MyFactory("byte");
            Console.WriteLine(myType.GetType().Name);

            myType = Program.MyFactory("float"); //3
            Console.WriteLine(myType.GetType().Name);

            Console.ReadKey();
        }

        static object MyFactory(string typeName)
        {
            object desiredType = null; //1
            switch (typeName)
            {
                case "byte": desiredType = new System.Byte(); break; //2
                case "long": desiredType = new System.Int64(); break;
                case "float": desiredType = new System.Single(); break;
                default: throw new System.NotImplementedException();
            }
            return desiredType;
        }
    }

यहाँ महत्वपूर्ण बिंदुओं: 1. फैक्टरी और अमूर्त तंत्र को वंशानुक्रम (System.Object-> बाइट, फ्लोट ...) का उपयोग करना चाहिए; इसलिए यदि आपके पास कार्यक्रम में विरासत है तो फैक्टरी (एब्सट्रैक्ट फैक्ट्री सबसे अधिक संभवत: वहां नहीं होगी) पहले से ही डिज़ाइन 2 में है। निर्माता (MyFactory) ठोस प्रकार के बारे में जानता है इसलिए कॉल करने वाले (मेन) को ठोस प्रकार की वस्तु लौटाता है; अमूर्त कारखाने में रिटर्न प्रकार एक इंटरफ़ेस होगा।

interface IVehicle { string VehicleName { get; set; } }
interface IVehicleFactory
    {
        IVehicle CreateSingleVehicle(string vehicleType);
    }
class HondaFactory : IVehicleFactory
    {
        public IVehicle CreateSingleVehicle(string vehicleType)
        {
            switch (vehicleType)
            {
                case "Sports": return new SportsBike();
                case "Regular":return new RegularBike();
                default: throw new ApplicationException(string.Format("Vehicle '{0}' cannot be created", vehicleType));
            }
        }
    }
class HeroFactory : IVehicleFactory
    {
        public IVehicle CreateSingleVehicle(string vehicleType)
        {
            switch (vehicleType)
            {
                case "Sports":  return new SportsBike();
                case "Scooty": return new Scooty();
                case "DarkHorse":return new DarkHorseBike();
                default: throw new ApplicationException(string.Format("Vehicle '{0}' cannot be created", vehicleType));
            }
        }
    }

class RegularBike : IVehicle { public string VehicleName { get { return "Regular Bike- Name"; } set { VehicleName = value; } } }
class SportsBike : IVehicle { public string VehicleName { get { return "Sports Bike- Name"; } set { VehicleName = value; } } }
class RegularScooter : IVehicle { public string VehicleName { get { return "Regular Scooter- Name"; } set { VehicleName = value; } } }
class Scooty : IVehicle { public string VehicleName { get { return "Scooty- Name"; } set { VehicleName = value; } } }
class DarkHorseBike : IVehicle { public string VehicleName { get { return "DarkHorse Bike- Name"; } set { VehicleName = value; } } }

class Program
{
    static void Main(string[] args)
    {
        IVehicleFactory honda = new HondaFactory(); //1
        RegularBike hondaRegularBike = (RegularBike)honda.CreateSingleVehicle("Regular"); //2
        SportsBike hondaSportsBike = (SportsBike)honda.CreateSingleVehicle("Sports");
        Console.WriteLine("******* Honda **********"+hondaRegularBike.VehicleName+ hondaSportsBike.VehicleName);

        IVehicleFactory hero = new HeroFactory();
        DarkHorseBike heroDarkHorseBike = (DarkHorseBike)hero.CreateSingleVehicle("DarkHorse");
        SportsBike heroSportsBike = (SportsBike)hero.CreateSingleVehicle("Sports");
        Scooty heroScooty = (Scooty)hero.CreateSingleVehicle("Scooty");
        Console.WriteLine("******* Hero **********"+heroDarkHorseBike.VehicleName + heroScooty.VehicleName+ heroSportsBike.VehicleName);

        Console.ReadKey();
    }
}

महत्वपूर्ण बिंदु: 1. आवश्यकता: होंडा "नियमित", "स्पोर्ट्स" बनाएगी, लेकिन हीरो "डार्कहोर्स", "स्पोर्ट्स" और "स्कूटी" बनाएगी। 2. दो इंटरफेस क्यों? एक निर्माता प्रकार (IVehicleFactory) के लिए और दूसरा उत्पाद कारखाने (IVehicle) के लिए; 2 इंटरफेस को समझने का दूसरा तरीका है सार फैक्ट्री सभी संबंधित वस्तुओं को बनाने के बारे में है। 2. पकड़ आईवीहिकलफैक्ट्री के बच्चों की वापसी और IVehicle (कारखाने में कंक्रीट के बजाय) है; इसलिए मुझे माता-पिता का चर (IVehicle) मिलता है; तब मैं CreateSingleVehicle को कॉल करके वास्तविक ठोस प्रकार बनाता हूं और फिर वास्तविक चाइल्ड ऑब्जेक्ट को पेरेंट ऑब्जेक्ट कास्टिंग करता हूं। अगर मैं करूँगा तो क्या होगा RegularBike heroRegularBike = (RegularBike)hero.CreateSingleVehicle("Regular");; आपको ApplicationException मिल जाएगी और इसीलिए हमें जेनेरिक एब्सट्रैक्ट फैक्ट्री की आवश्यकता है, जिसे मैं आवश्यकता होने पर समझाऊंगा।

Answer 13

सार फैक्टरी : कारखानों का एक कारखाना; एक कारखाना जो अपने ठोस वर्गों को निर्दिष्ट किए बिना व्यक्तिगत लेकिन संबंधित / निर्भर कारखानों को एक साथ समूहित करता है। सार फैक्टरी उदाहरण

फैक्टरी : यह बच्चे की कक्षाओं के लिए तात्कालिकता तर्क को सौंपने का एक तरीका प्रदान करता है। फैक्टरी पैटर्न उदाहरण

Answer 14

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

Answer 15

मुझे इसे ठीक करने की अनुमति दें। अधिकांश उत्तर पहले ही बता चुके हैं, चित्र और उदाहरण भी। तो मेरी awer सिर्फ एक लाइनर होगा। मेरे अपने शब्द: - “अमूर्त कारखाना पैटर्न कई कारखाने विधि कार्यान्वयन पर सार परत पर जोड़ता है। अमूर्त कारखाने का मतलब है या एक या एक से अधिक कारखाने विधि पैटर्न शामिल हैं ”

Comments

यह सही नहीं है। यह सर्व-आम गलत धारणा है कि सार फैक्टरी कारखानों के कारखाने से ज्यादा कुछ नहीं है।

— jaco0646

Answer 16

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

जैसा कि GoF aptly कहता है: Abstract Factory अपने ठोस वर्गों को निर्दिष्ट किए बिना संबंधित या आश्रित वस्तुओं के परिवारों को बनाने के लिए एक इंटरफ़ेस प्रदान करता है।

        public class Client {
            public static void main(String[] args) {
               ZooFactory zooFactory = new HerbivoreZooFactory();       
               Animal animal1 = zooFactory.animal1();
               Animal animal2 = zooFactory.animal2();
               animal1.sound();
               animal2.sound();

               System.out.println();

               AnimalFactory animalFactory = new CowAnimalFactory();
               Animal animal = animalFactory.createAnimal();
               animal.sound();
            }
        }

        public interface Animal {
            public void sound();
        }

        public class Cow implements Animal {

            @Override
            public void sound() {
                System.out.println("Cow moos");
            }

        }

        public class Deer implements Animal {

            @Override
            public void sound() {
                System.out.println("Deer grunts");
            }

        }

        public class Hyena implements Animal {

            @Override
            public void sound() {
                System.out.println("Hyena.java");
            }

        }

        public class Lion implements Animal {

            @Override
            public void sound() {
                System.out.println("Lion roars");
            }

        }

        public interface ZooFactory {
            Animal animal1();

            Animal animal2();
        }

        public class CarnivoreZooFactory implements ZooFactory {

            @Override
            public Animal animal1() {
                return new Lion();
            }

            @Override
            public Animal animal2() {
                return new Hyena();
            }

        }

        public class HerbivoreZooFactory implements ZooFactory{

            @Override
            public Animal animal1() {
                return new Cow();
            }

            @Override
            public Animal animal2() {
                return new Deer();
            }

        }

        public interface AnimalFactory {
            public Animal createAnimal();
        }

        public class CowAnimalFactory implements AnimalFactory{

            @Override
            public Animal createAnimal() {
                return new Cow();
            }

        }

        public class DeerAnimalFactory implements AnimalFactory{

            @Override
            public Animal createAnimal() {
                return new Deer();
            }

        }

        public class HyenaAnimalFactory implements AnimalFactory{

            @Override
            public Animal createAnimal() {
                return new Hyena();
            }

        }

        public class LionAnimalFactory implements AnimalFactory{

            @Override
            public Animal createAnimal() {
                return new Lion();
            }

        }

Comments

यह सही नहीं है। यह कोड ऑल-बहुत-आम गलत धारणा को लागू करता है कि एब्सट्रैक्ट फैक्ट्री फैक्ट्री से ज्यादा कुछ नहीं है।

— jaco0646

@ jaco0646 मेरा मानना ​​है कि फैक्टरी विधि पैटर्न में, FactoryImpl से केवल एक ठोस उत्पाद प्राप्त करने पर ध्यान दिया जाता है। जबकि अमूर्त कारखाने पैटर्न में, FactoryImpls कई समान / संबंधित कंक्रीटप्रोडक्ट प्रदान करने के लिए जिम्मेदार हैं, जिसके लिए फ़ैक्टरी इंटरफ़ेस एक अनुबंध प्रदान करता है। तो चिड़ियाघरफैक्ट्री फैक्ट्री के सभी कारखानों में नहीं है, जैसा कि आप कहते हैं, लेकिन सिर्फ एक इंटरफ़ेस जिसका इम्प्लेक्स कंक्रीट उत्पाद प्रदान करता है जो एक दूसरे से संबंधित हैं। यदि आप असहमत हैं तो मेरी समझ को ठीक करने के लिए स्वतंत्र महसूस करें।

— जतिन शशू

फैक्ट्री मेथड में, सब-क्लासिंग के माध्यम से इनहेरिटेंस पर ध्यान दिया जाता है, क्योंकि फैक्ट्री मेथड टेंपलेट मेथड का एक स्पेशलाइजेशन है। ऊपर-ऊपर दिया गया उत्तर एक सभ्य कोड उदाहरण दिखाता है।

— jaco0646

@ jaco0646 1. क्या इसका मतलब यह है कि उपरोक्त उदाहरण में, AnimalFactory के लिए इंटरफेस का उपयोग करने और इसके कार्यान्वयन प्रदान करने के बजाय, मुझे एक वर्ग का उपयोग करना चाहिए और इसके उपवर्गों में createAnimal () विधि का उपयोग करना चाहिए: CownnimalFactory, LionAnimalFactory, आदि। ?? 2. इसके अलावा, ZooFactory के लिए दिखाए गए उदाहरण के बारे में उर के विचार क्या हैं ??

— जतिन शाशु

पहले सवाल पर: हाँ। दूसरे के लिए, मैंने इस थ्रेड के लिए अपना स्वयं का उत्तर जोड़ा है बजाय प्रत्येक व्यक्तिगत उत्तर को क्रिटीक किए जारी रखने के लिए।

— jaco0646