factory pattern - सार फैक्टरी पैटर्न और फैक्टरी विधि के बीच मतभेद




factory-pattern factory-method (8)

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

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

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

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

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

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

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


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

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

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

  1. क्या अमूर्त फैक्ट्री केवल आपके द्वारा कॉल की जाने वाली विधियों के आधार पर एक बहुत बड़ी वस्तु या कई वस्तुएं लौटाती है?

आदर्श रूप से इसे विधि क्लाइंट के आविष्कार के अनुसार एक ऑब्जेक्ट वापस करना चाहिए।

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

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

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

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

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

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

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


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

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

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

... फैक्टरी विधि पैटर्न विरासत का उपयोग करता है और इच्छित ऑब्जेक्ट त्वरण को संभालने के लिए उप-वर्ग पर निर्भर करता है।

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

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

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

वे क्या कह रहे हैं कि एक वस्तु ए है, जो एक फू ऑब्जेक्ट बनाना चाहता है। फू ऑब्जेक्ट को स्वयं बनाने के बजाए (उदाहरण के लिए, फ़ैक्टरी विधि के साथ), इसे 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

न्यूनतम इंटरफ़ेस के साथ इसे बहुत आसान बनाने के लिए और कृपया "// 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 है। निर्माता (माईफैक्टरी) कंक्रीट प्रकार के बारे में जानता है इसलिए कॉलर (मुख्य) को कंक्रीट प्रकार ऑब्जेक्ट देता है; अमूर्त कारखाने में वापसी का प्रकार एक इंटरफ़ेस होगा।

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 इंटरफेस को समझने का दूसरा तरीका अमूर्त कारखाना संबंधित वस्तुओं को बनाने के बारे में है। पकड़ आईवीहिकल फैक्ट्री के बच्चे लौटने और चतुर्थ (कारखाने में ठोस के बजाय) है; इसलिए मुझे पैरेंट वैरिएबल (IVehicle) मिलता है; तो मैं CreateSingleVehicle को कॉल करके और फिर मूल ऑब्जेक्ट को मूल ऑब्जेक्ट कास्टिंग करके वास्तविक ठोस प्रकार बना देता हूं। अगर मैं RegularBike heroRegularBike = (RegularBike)hero.CreateSingleVehicle("Regular"); करता हूं तो क्या होगा। RegularBike heroRegularBike = (RegularBike)hero.CreateSingleVehicle("Regular"); ; आपको एप्लीकेशन अपवाद प्राप्त होगा और यही कारण है कि हमें जेनेरिक अमूर्त फैक्ट्री की आवश्यकता है जो आवश्यक होने पर मैं समझाऊंगा। उम्मीद है कि यह शुरुआती से मध्यवर्ती दर्शकों तक मदद करता है।


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


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

फ़ैक्टरी

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

सार फैक्टरी

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

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


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


प्रेरणा में मतभेदों को समझें:

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

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

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

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

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

कुछ नोट्स:

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

नमूना कोड:

//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
    }
    ….
}

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

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

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

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