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

Question

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

कौन सा अधिक फायदेमंद है और क्यों?

यदि मैं इन पैटर्नों का परीक्षण और तुलना / तुलना करना चाहता हूं तो मैं एक ग्राफ के रूप में अपने निष्कर्षों का प्रतिनिधित्व कैसे करूं?

Comments

चूंकि वे अलग-अलग काम करते हैं, तो आपको "लाभप्रद" से क्या मतलब है?

— एस.लॉट

बिल्डर कंस्ट्रक्टर का एक अधिक जटिल संस्करण है - जबकि फैक्टरी विधि एक सरलीकृत है।

— दविद होर्वथ

@ Dvvidhorváth मैं किसी बिल्डर को "अधिक जटिल" नहीं बताता। जब आप एक ऐसे निर्माता के साथ काम कर रहे हों जिसमें 100 पैरामीटर हों, और आप केवल उनमें से 3 की परवाह करते हैं, और आप जानते हैं कि भविष्य में मापदंडों की संख्या बदल सकती है, तो बिल्डर पैटर्न का उपयोग करके सभी का जीवन बहुत सरल हो जाएगा।

— अब्राहम

@ अब्रंटेड जटिल उपयोग और वास्तु जटिलता दो अलग-अलग चीजें हैं। मैंने बाद वाले पर ध्यान केंद्रित किया।

— दविद होर्वाथ

Answer 1

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

विकिपीडिया से:

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

फैक्टरी डिजाइन पैटर्न के लिए विकिपीडिया प्रविष्टि: http://en.wikipedia.org/wiki/Factory_method_pattern

बिल्डर डिजाइन पैटर्न के लिए विकिपीडिया प्रविष्टि: http://en.wikipedia.org/wiki/Builder_pattern

Comments

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

— बर्नार्ड इगिरि

पहले वाक्य के लिए, मैं कहूंगा कि वास्तव में अक्सर एक अधिक लाभकारी समाधान होता है जो मोटे तौर पर लागू होता है ... हम सिर्फ ये नहीं देखते हैं, क्योंकि वे सीधे प्रोग्रामिंग भाषाओं में बेक किए जाते हैं।

— जोएल कोएहॉर्न

@ जॉयल: मैं मानता हूं कि कुछ पैटर्न अधिक सामान्य हैं जो अन्य (उदाहरण के लिए, फैक्ट्री बिल्डर की तुलना में अधिक सामान्य प्रतीत होते हैं), लेकिन मेरा क्या मतलब है कि उनमें से कोई भी हमेशा दूसरे की तुलना में बेहतर है, कोई फर्क नहीं पड़ता कि परिदृश्य कैसा दिखता है ।

— एड्रियन ग्रिगोर

@ AdrianGrigore क्या होगा अगर दोनों को मिलाते हैं ?? aso.net mvc के पास कंट्रोलरबर्ल है जिन्होंने सेट किया है और कंट्रोलरफाइटलिंग क्लास के लिए विधि प्राप्त करें

— AminM

उत्तर उत्तर, हालांकि 2 चीजें जो जोड़ने लायक है: 1) बिल्डर का उपयोग मुख्य रूप से धाराप्रवाह एपीआई (जैसे व्यक्ति। व्यक्ति) (.Name ("सैम") का उपयोग करके POJO का निर्माण करने के लिए किया जाता है। withAge (38) .build (2)। मेरे अनुभवी में, बिल्डर डोमेन ऑब्जेक्ट्स के लिए POJO निर्माण के लिए उपयोगी है, जबकि फैक्ट्री PdfGeneratorFactory वर्ग जैसी सर्विस ऑब्जेक्ट बनाने के लिए उपयोगी है। सेवा ऑब्जेक्ट को 1 से अधिक समय के उपयोग के लिए कारखाने के भीतर कैश किया जा सकता है, जबकि बिल्डर हमेशा डिज़ाइन द्वारा एक नई वस्तु बनाता है।

— saurabh.in

Answer 2

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

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

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

मूल कारखाना उदाहरण

// Factory
static class FruitFactory {
    static Fruit create(name, color, firmness) {
        // Additional logic
        return new Fruit(name, color, firmness);
    }
}

// Usage
Fruit fruit = FruitFactory.create("apple", "red", "crunchy");

मूल बिल्डर उदाहरण

// Builder
class FruitBuilder {
    String name, color, firmness;
    FruitBuilder setName(name)         { this.name     = name;     return this; }
    FruitBuilder setColor(color)       { this.color    = color;    return this; }
    FruitBuilder setFirmness(firmness) { this.firmness = firmness; return this; }
    Fruit build() {
        return new Fruit(this); // Pass in the builder
    }
}

// Usage
Fruit fruit = new FruitBuilder()
        .setName("apple")
        .setColor("red")
        .setFirmness("crunchy")
        .build();

यह इन दो विकिपीडिया पृष्ठों के कोड नमूनों की तुलना करने के लायक हो सकता है:

http://en.wikipedia.org/wiki/Factory_method_pattern
http://en.wikipedia.org/wiki/Builder_pattern

Comments

बिल्डर पैटर्न imo का सही उपयोग नहीं है, यहां तक ​​कि आपके द्वारा उपयोग किए गए विकी लिंक में भी अलग है। यह FruitBuilder निर्देशक और बिल्डर घटक का कुछ मिश्रण है जहां आप बिल्ड () का निर्माण करते हैं जो निर्देशक से संबंधित होना चाहिए और जो बिल्डर घटक से संबंधित है। डायरेक्टर को बिल्डरों के तरीकों का उपयोग करके ऑब्जेक्ट बनाने के लिए व्यावसायिक तर्क होना चाहिए। धाराप्रवाह एपिस बिल्डर पैटर्न नहीं हैं और स्ट्रिंगबर्ल भी बिल्डर पैटर्न नहीं हैं।

— Kmaczek

Answer 3

फैक्टरी पैटर्न को लगभग बिल्डर पैटर्न के सरलीकृत संस्करण के रूप में देखा जा सकता है।

में फैक्टरी पैटर्न, कारखाने जरूरतों के आधार पर एक वस्तु के विभिन्न उपप्रकार बनाने के आरोप में है।

फ़ैक्टरी विधि के उपयोगकर्ता को उस वस्तु के सटीक उपप्रकार को जानने की आवश्यकता नहीं है। फ़ैक्टरी विधि का एक उदाहरण createCarएक Fordया Hondaटाइप की गई वस्तु को वापस कर सकता है ।

में बिल्डर पैटर्न, विभिन्न उपप्रकार भी एक बिल्डर विधि द्वारा बनाई गई हैं, लेकिन वस्तुओं की संरचना एक ही उपवर्ग के भीतर भिन्न हो सकती है।

कार के उदाहरण को जारी रखने के लिए आपके पास एक createCarबिल्डर विधि हो सकती है जो Honda4 सिलेंडर इंजन के Hondaसाथ -typed ऑब्जेक्ट या 6 सिलेंडर के साथ -typed ऑब्जेक्ट बनाती है। बिल्डर पैटर्न इस बारीक ग्रैन्युलैरिटी के लिए अनुमति देता है।

बिल्डर पैटर्न और फैक्टरी विधि पैटर्न दोनों के आरेख विकिपीडिया पर उपलब्ध हैं।

Comments

बिल्डर पैटर्न बड़ी वस्तु के निर्माण में ज़ूम करने जैसा है। बड़ी वस्तु अन्य वस्तु से बनी होती है जो आगे की तरह पुनरावृत्ति पर बनी होती है। जबकि फैक्ट्री आपको सिर्फ एक कॉल में चीज दिलवा देगी। क्या यह समझ सही है?

— फू जूल 9'14

Answer 4

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

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

Comments

बस कुछ संकेत: बिल्डर पैटर्न के लिए अच्छा उदाहरण "धाराप्रवाह इंटरफ़ेस" है और ADO.NET "कारखाने" और "सार कारखाने" कार्यान्वयन (यानी। DFFactory) के साथ भरा हुआ है।

— बोज

Answer 5

• एक जटिल वस्तु कदम से कदम का निर्माण: बिल्डर पैटर्न

• एक साधारण वस्तु एकल विधि का उपयोग करके बनाई गई है: कारखाना विधि पैटर्न

• कई कारखाने विधि का उपयोग करके ऑब्जेक्ट बनाना: सार फैक्टरी पैटर्न

Answer 6

बिल्डर पैटर्न और फैक्टरी पैटर्न, दोनों नग्न आंखों के समान सुंदर लगते हैं क्योंकि वे दोनों आपके लिए ऑब्जेक्ट बनाते हैं।

लेकिन आपको करीब से देखने की जरूरत है

यह वास्तविक जीवन का उदाहरण दोनों के बीच अंतर को स्पष्ट करेगा।

मान लीजिए, आप एक फास्ट फूड रेस्तरां में गए और आपने फूड ऑर्डर किया ।

1) क्या खाना?

पिज़्ज़ा

2) क्या टॉपिंग?

शिमला मिर्च, टमाटर, बीबीक्यू चिकन, NO PINEAPPLE

इसलिए विभिन्न प्रकार के खाद्य पदार्थ फैक्ट्री पैटर्न द्वारा बनाए जाते हैं लेकिन किसी विशेष भोजन के विभिन्न प्रकार (फ्लेवर) बिल्डर पैटर्न द्वारा बनाए जाते हैं।

विभिन्न प्रकार के खाद्य पदार्थ

पिज्जा, बर्गर, पास्ता

पिज्जा के वेरिएंट

केवल पनीर, पनीर + टमाटर + शिमला मिर्च, पनीर + टमाटर आदि।

कोड नमूना

आप यहां दोनों पैटर्न का नमूना कोड कार्यान्वयन देख सकते हैं
बिल्डर पैटर्न
फैक्टरी पैटर्न

Comments

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

— रोमेल पारस

Answer 7

ऑब्जेक्ट बनाने के लिए दोनों क्रिएशनल पैटर्न हैं।

1) फैक्टरी पैटर्न - मान लें, आपके पास एक सुपर क्लास और एन संख्या उप कक्षाएं हैं। ऑब्जेक्ट बनाया गया है जो पैरामीटर / मान पारित किया गया है पर निर्भर करता है।

2) बिल्डर पैटर्न - जटिल वस्तु बनाने के लिए।

Ex: Make a Loan Object. Loan could be house loan, car loan ,
    education loan ..etc. Each loan will have different interest rate, amount ,  
    duration ...etc. Finally a complex object created through step by step process.

Answer 8

मेरे तर्क का पालन करने के लिए पहले कुछ सामान्य बातें:

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

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

प्रश्न का उत्तर दे रहा है:

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

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

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

बिल्डर पैटर्न: GoF: "एक जटिल वस्तु के निर्माण को उसके प्रतिनिधित्व से अलग करें ताकि एक ही निर्माण प्रक्रिया में अलग-अलग बदलाव शामिल हो सकें।"

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

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

मेरी राय में आप यह नहीं कह सकते कि एब्सट्रैक्ट फ़ैक्टरी पैटर्न बिल्डर पैटर्न का बड़ा भाई है। हाँ, वे दोनों रचनात्मक पैटर्न हैं, लेकिन पैटर्न का मुख्य इरादा पूरी तरह से अलग है।

Comments

अच्छा जवाब, विस्तृत विवरण।

— टॉरी

क्या आप कृपया "उसके प्रतिनिधित्व से एक जटिल वस्तु के निर्माण को अलग" का अर्थ समझा सकते हैं

— राजदीप

@ राजदीप की व्याख्या एक टिप्पणी के लिए लंबे समय तक है, इसीलिए मैंने एक और उत्तर लिखा है।

— जैनिस

@ जानिस वह उत्तर या स्रोत जहाँ से मैं पढ़ सकता हूँ?

— राजदीप

@ राजदीप

— Janis

Answer 9

बिल्डर और फैक्टरी के बीच एक अंतर जो मैं कर सकता था वह निम्नलिखित था

मान लीजिए हमारे पास एक कार है

class Car
{
  bool HasGPS;
  bool IsCityCar;
  bool IsSportsCar;
  int   Cylenders;
  int Seats;

  public:
     void Car(bool hasGPs=false,bool IsCityCar=false,bool IsSportsCar=false, int Cylender=2, int Seats=4);
 };

उपरोक्त इंटरफ़ेस में हम निम्नलिखित तरीके से कार प्राप्त कर सकते हैं:

 int main()
 {
    BadCar = new Car(false,false,true,4,4);
  }

लेकिन क्या होगा, अगर सीट्स बनाते समय कुछ अपवाद होता है ??? आप सभी पर / लेकिन इस तरह का लाभ नहीं मिलेगा

मान लें कि आपके पास निम्नलिखित की तरह कार्यान्वयन है

class Car
 {
    bool mHasGPS;
    bool mIsCityCar;
    bool mIsSportsCar;
    int mCylenders;
    int mSeats;

 public:
    void Car() : mHasGPs(false), mIsCityCar(false), mIsSportsCar(false), mCylender(2), mSeats(4) {}
    void SetGPS(bool hasGPs=false)  {mHasGPs = hasGPs;}
    void SetCity(bool CityCar)  {mIsCityCar = CityCar;}
    void SetSports(bool SportsCar)  {mIsSportsCar = SportsCar;}
    void SetCylender(int Cylender)  {mCylenders = Cylender;}    
    void SetSeats(int seat) {mSeats = seat;}    
};

 class CarBuilder 
 {
    Car* mCar;
public:
        CarBuilder():mCar(NULL) {   mCar* = new Car();  }
        ~CarBuilder()   {   if(mCar)    {   delete mCar;    }
        Car* GetCar()   {   return mCar; mCar=new Car();    }
        CarBuilder* SetSeats(int n) {   mCar->SetSeats(n); return this; }
        CarBuilder* SetCylender(int n)  {   mCar->SetCylender(n); return this;  }
        CarBuilder* SetSports(bool val) {   mCar->SetSports(val); return this;  }
        CarBuilder* SetCity(bool val)   {   mCar->SetCity(val); return this;    }
        CarBuilder* SetGPS(bool val)    {   mCar->SetGPS(val); return this; }
}

अब आप इस तरह से बना सकते हैं

 int main()
 {
   CarBuilder* bp =new CarBuilder;
    Car* NewCar  = bp->SetSeats(4)->SetSports(4)->SetCity(ture)->SetGPS(false)->SetSports(true)->GetCar();

     bp->SetSeats(2);

     bp->SetSports(4);

     bp->SetCity(ture);

     bp->SetSports(true)

     Car* Car_II=  bp->GetCar();

  }

यहां दूसरे मामले में, भले ही एक ऑपरेशन विफल हो जाए फिर भी आपको कार मिल जाएगी।

हो सकता है कि कार पूरी तरह से बाद में काम न करे लेकिन, आपके पास वस्तु होगी।

क्योंकि फैक्ट्री मेथड आपको कार को सिंगल कॉल में देता है, जबकि बिल्डर एक-एक करके बनाता है।

हालांकि, यह उस पद की जरूरतों पर निर्भर करता है जिसके लिए जाना है।

Comments

निश्चित रूप से अमान्य कार की तुलना में कोई कार नहीं होना बेहतर है - क्या होगा यदि आप केवल ब्रेक का उपयोग करने के लिए आने पर समस्या पाते हैं?

— केन

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

— फूओ

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

— केन

Answer 10

+-------------------------------------------------------------------+---------------------------------------------------+
|                              Builder                              |                      Factory                      |
+-------------------------------------------------------------------+---------------------------------------------------+
| Return only single instance to handle complex object construction | Retrun various instances on multiple constructors |
| No interface required                                             | Interface driven                                  |
| Inner classes is involved (to avoid telescopic constructors)      | Subclasses are involved                           |
+-------------------------------------------------------------------+---------------------------------------------------+  

टेलिस्कोपिंग कंस्ट्रक्टर पैटर्न

सादृश्य:

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

के सौजन्य से

Answer 11

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

बिल्डर मुख्य विशेषताएं:

1. बिल्डर पैटर्न सरल वस्तुओं का उपयोग करके और चरण दृष्टिकोण द्वारा एक कदम का उपयोग करके एक जटिल वस्तु बनाता है
2. एक बिल्डर क्लास स्टेप बाय स्टेप अंतिम ऑब्जेक्ट बनाता है। यह बिल्डर अन्य वस्तुओं से स्वतंत्र है
3. इस पद्धति में फ़ैक्टरी विधि / अमूर्त फ़ैक्ट्री के लिए प्रतिस्थापन: क्लाइंट प्रोग्राम से फ़ैक्टरी क्लास तक पारित करने के लिए बहुत सारे तर्क जो कि मुश्किल हो सकते हैं
4. कुछ पैरामीटर फैक्ट्री के विपरीत वैकल्पिक हो सकते हैं जो सभी मापदंडों को भेजने के लिए मजबूर करते हैं

फैक्टरी (सरल कारखाना) मुख्य विशेषताएं:

1. रचनात्मक पैटर्न
2. वंशानुक्रम के आधार पर
3. फैक्ट्री एक फैक्ट्री मेथड (इंटरफ़ेस) देता है जो बदले में ठोस वस्तु देता है
4. आप इंटरफ़ेस और क्लाइंट (कॉलर) के लिए नए कंक्रीट ऑब्जेक्ट को स्थानापन्न कर सकते हैं, सभी ठोस कार्यान्वयन के बारे में पता नहीं होना चाहिए
5. क्लाइंट हमेशा केवल इंटरफ़ेस का उपयोग करता है और आप फैक्टरी विधि में ऑब्जेक्ट निर्माण विवरण छिपा सकते हैं।

अक्सर, डिज़ाइन फैक्ट्री मेथड (कम जटिल, अधिक अनुकूलन योग्य, उपवर्ग प्रोलिफ़रेट) का उपयोग करके शुरू होता है और एब्सट्रैक्ट फ़ैक्टरी , प्रोटोटाइप या बिल्डर (अधिक लचीला, अधिक जटिल) की ओर विकसित होता है

संबंधित पदों पर एक नजर:

बिल्डर को अलग वर्ग में रखना (धाराप्रवाह इंटरफ़ेस)

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

आप अधिक जानकारी के लिए नीचे दिए गए लेख देख सकते हैं:

sourcemaking

journaldev

Answer 12

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

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

Answer 13

एब्सट्रैक्ट फैक्ट्री और बिल्डर पैटर्न दोनों क्रिएशनल पैटर्न हैं, लेकिन अलग इरादे से।

सार फैक्ट्री पैटर्न संबंधित वस्तुओं के परिवारों के लिए वस्तु निर्माण पर जोर देता है जहां:

• प्रत्येक परिवार एक सामान्य आधार वर्ग / इंटरफ़ेस से प्राप्त वर्गों का एक समूह है।
• प्रत्येक ऑब्जेक्ट को एक कॉल के परिणामस्वरूप तुरंत लौटा दिया जाता है।

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

• बिल्डर ऑब्जेक्ट कॉम्प्लेक्स ऑब्जेक्ट के कॉन्फ़िगरेशन को एन्क्रिप्ट करता है।
• निर्देशक ऑब्जेक्ट बिल्डर के उपयोग के प्रोटोकॉल को जानता है, जहां प्रोटोकॉल जटिल ऑब्जेक्ट के निर्माण के लिए आवश्यक सभी तार्किक चरणों को परिभाषित करता है।

Comments

क्या आप कृपया "जटिल वस्तु के निर्माण की प्रक्रिया से प्रतिनिधित्व को प्रदर्शित करता है" का अर्थ समझा सकते हैं

— राजदीप

Answer 14

एक जटिल निर्माण तब होता है जब निर्माण की जाने वाली वस्तु विभिन्न अन्य वस्तुओं से बनी होती है जो कि अमूर्त द्वारा दर्शाई जाती हैं।

मैकडॉनल्ड्स में एक मेनू पर विचार करें। एक मेनू में एक पेय, एक मुख्य और एक पक्ष होता है। जिसके आधार पर व्यक्तिगत अमूर्त के वंशज एक साथ रचे गए हैं, निर्मित मेनू में एक और प्रतिनिधित्व है।

1. उदाहरण: कोला, बिग मैक, फ्रेंच फ्राइज़
2. उदाहरण: स्प्राइट, नगेट्स, कर्ली फ्राइज़

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

बिल्डर पैटर्न का उपयोग करके, आप इसे बनाने के लिए उपयोग किए गए विभिन्न घटकों से एक जटिल ऑब्जेक्ट बनाने के एल्गोरिथ्म को अलग करते हैं।

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

Comments

यह "प्रतिनिधित्व से जटिल वस्तु के निर्माण को अलग करना" बताता है

— राजदीप

Answer 15

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

उदाहरण: मान लीजिए कि हम भूलभुलैया बना रहे हैं

1. सार फैक्टरी:

Maze* MazeGame::CreateMaze (MazeFactory& factory) {
Maze* maze = factory.MakeMaze(); /// product is available at start!!
 /* Call some methods on maze */
return maze;
}

2. बिल्डर:

Maze* MazeGame::CreateMaze (MazeBuilder& builder) {
builder.buildMaze(); /// We don't have access to maze
 /* Call some methods on builder */
return builder.GetMaze();
}

Answer 16

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

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

यह बिंदु संभवतः संक्रमण / विस्तार बिंदु होगा। ऐसा करके, आप निर्माण मापदंडों के आसपास एक आवरण मॉड्यूल बनाते हैं और फिर आप अपने निर्माण तर्क को छूने के बिना कुछ और सार (शायद) और कार्यान्वयन जोड़कर नई (समान) वस्तुओं का प्रतिनिधित्व कर पाएंगे। तो आपके पास "कम" जटिल तर्क है।

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

Answer 17

फैक्ट्री पैटर्न पर बिल्डर पैटर्न का मुख्य लाभ उस स्थिति में है जब आप बहुत सारे संभव अनुकूलन के साथ कुछ मानक ऑब्जेक्ट बनाना चाहते हैं, लेकिन आप आमतौर पर कस्टमाइज़िंग को कुछ ही समाप्त करते हैं।

उदाहरण के लिए, यदि आप एक HTTP क्लाइंट लिखना चाहते हैं - तो आप कुछ डिफ़ॉल्ट पैरामीटर सेट करेंगे जैसे डिफ़ॉल्ट राइट / टाइमआउट, प्रोटोकॉल, कैश, डीएनएस, इंटरसेप्टर, आदि।

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

यहां आपके क्लाइंट को तत्काल सक्षम करने के संभावित तरीके हैं (OkHttpClient से लिया गया है):

//just give me the default stuff
HttpClient.Builder().build()   

//I want to use custom cache
HttpClient.Builder().cache(MyCache()).build() 

//I want custom connection timeout
HttpClient.Builder().connectTimeout(30, TimeUnit.SECONDS).build() 

//I am more interested in read/write timeout
HttpClient.Builder()
        .readTimeout(30, TimeUnit.SECONDS)
        .writeTimeout(30, TimeUnit.SECONDS).build()

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

Answer 18

बिल्ड पैटर्न जटिलता पर जोर देता है ऑब्जेक्ट बनाने की ("चरणों द्वारा हल")

अमूर्त पैटर्न (एकाधिक लेकिन संबंधित) वस्तुओं के "अमूर्त" पर "बस" पर जोर देता है।

Answer 19

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

यहां बिल्डर वर्ग मुख्य वर्ग और विशिष्ट प्रकार की कक्षाओं के बीच मध्यस्थ के रूप में कार्य करता है। अधिक अमूर्तता।

Answer 20

दोनों बहुत समान हैं, लेकिन यदि आपके पास ऑब्जेक्ट के निर्माण के लिए बड़ी संख्या में पैरामीटर हैं, जिनमें से कुछ डिफ़ॉल्ट मानों के साथ वैकल्पिक हैं, तो बिल्डर पैटर्न के लिए जाएं।

Answer 21

IMHO

बिल्डर किसी प्रकार का अधिक जटिल कारखाना है।

लेकिन बिल्डर में आप एक और कारखानों का उपयोग करने के साथ वस्तुओं को तुरंत कर सकते हैं हैं, जो अंतिम और वैध वस्तु के निर्माण के लिए आवश्यक हैं।

तो, "क्रिएशनल पैटर्न" के विकास के बारे में बात करना जटिलता से आप इस बारे में सोच सकते हैं:

Dependency Injection Container -> Service Locator -> Builder -> Factory

Answer 22

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

उस जटिलता पर हावी होने के दो प्रसिद्ध तरीके हैं:

• रचना / एकत्रीकरण: किसी वस्तु का निर्माण, उसके आश्रित वस्तुओं का निर्माण, फिर एक साथ तार। यहां, एक बिल्डर पारदर्शी और लचीली प्रक्रिया बना सकता है जो उन नियमों को निर्धारित करता है जो घटक के निर्माण का नेतृत्व करते हैं।

• बहुरूपता: निर्माण नियमों को सीधे उपप्रकार परिभाषा में घोषित किया जाता है, इसलिए आपके पास प्रत्येक उपप्रकार के लिए नियमों का एक सेट होता है और कुछ शर्त यह तय करती है कि इनमें से कौन सा नियम वस्तु के निर्माण के लिए लागू होता है। एक कारखाना इस परिदृश्य में पूरी तरह से फिट बैठता है।

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

Answer 23

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

जबकि फैक्ट्री पैटर्न यह निर्दिष्ट करता है कि आप एक सामान्य परिवार की वस्तुएँ बनाना चाहते हैं और आप चाहते हैं कि इसे एक ही बार में व्यवस्थित किया जाए। इसका उपयोग सरल वस्तुओं के लिए किया जाता है।

Answer 24

बिल्डर और एब्सट्रैक्ट फैक्ट्री

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

उत्पादों के लिए सामान्य इंटरफ़ेस

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

प्रेषक: http://www.oodesign.com/builder-pattern.html

Answer 25

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

इन दो पैटर्नों का एकमात्र सामान्य विषय है, निर्माण के तरीकों और फैक्ट्री निर्माण के पीछे ऑब्जेक्ट निर्माण, और बेहतर निर्माण के लिए निर्माण विधि का छिपाना।

Answer 26

फैक्टरी पैटर्न आपको एक बार में एक ऑब्जेक्ट बनाने की अनुमति देता है जबकि बिल्डर पैटर्न आपको एक ऑब्जेक्ट की निर्माण प्रक्रिया को तोड़ने देता है। इस तरह, आप किसी ऑब्जेक्ट के निर्माण के दौरान विभिन्न कार्यक्षमता जोड़ सकते हैं।