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




design-patterns factory-pattern (21)

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

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

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


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

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

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

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

से: http://www.oodesign.com/builder-pattern.html


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

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


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

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

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

सवाल का जवाब:

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

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

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

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

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

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

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


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

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

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

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

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

http://en.wikipedia.org/wiki/Builder_pattern और http://en.wikipedia.org/wiki/Factory_method_pattern दोनों के चित्र विकिपीडिया पर उपलब्ध हैं।


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

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

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

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


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

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


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

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

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();

  }

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

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

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

हालांकि, यह इस बात पर निर्भर करता है कि किसके लिए जाना है।


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

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

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

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

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

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

संबंधित पदों पर एक नज़र डालें:

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

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

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

sourcemaking

journaldev


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

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

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

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


सार कारखाना बिल्डर के समान है जिसमें यह जटिल वस्तुओं का निर्माण भी कर सकता है। प्राथमिक अंतर यह है कि बिल्डर पैटर्न चरणबद्ध रूप से जटिल ऑब्जेक्ट चरण बनाने पर केंद्रित है। सार कारक का जोर उत्पाद वस्तुओं के परिवारों (या तो सरल या जटिल) पर है।


IMHO

बिल्डर कुछ प्रकार की जटिल फैक्ट्री है।

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

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

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

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


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

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


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

नमूना

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

namespace ConsoleApp_Design_Patterns
{

    class BuilderDesignPattern
    {
        static void Main(string[] args)
        {
            //create a constructor object to start building
            Kid aKid = new Kid();
            aKid.Name = "Elizabeth";

            //Elizabeth use Monkey mold to make a monkey
            Console.WriteLine("{0} start making a monkey", aKid.Name);
            AnimalBuilder builderA = new MonkeyBuilder();
            aKid.MakeAnimal(builderA);
            builderA.aAnimal.ShowMe();

            //Elizabeth use Kitten mold to make a kitten
            Console.WriteLine("{0} start making a kitten", aKid.Name);
            AnimalBuilder builderB = new KittenBuilder();
            aKid.MakeAnimal(builderB);
            builderB.aAnimal.ShowMe();

            Console.Read();
        }
    }
    public abstract class AnimalBuilder
    {
        public Animal aAnimal;

        public abstract void BuildAnimalHeader();
        public abstract void BuildAnimalBody();
        public abstract void BuildAnimalLeg();
        public abstract void BuildAnimalArm();
        public abstract void BuildAnimalTail();
    }
    public class MonkeyBuilder : AnimalBuilder
    {

        public MonkeyBuilder()
        {
            aAnimal = new Monkey();
        }

        public override void BuildAnimalHeader()
        {
            aAnimal.Head = "Moneky's Head has been built";
        }

        public override void BuildAnimalBody()
        {
            aAnimal.Body = "Moneky's Body has been built";
        }

        public override void BuildAnimalLeg()
        {
            aAnimal.Leg = "Moneky's Leg has been built";
        }

        public override void BuildAnimalArm()
        {
            aAnimal.Arm = "Moneky's Arm has been built";
        }

        public override void BuildAnimalTail()
        {
            aAnimal.Tail = "Moneky's Tail has been built";
        }
    }
    public class KittenBuilder : AnimalBuilder
    {
        public KittenBuilder()
        {
            aAnimal = new Kitten();
        }

        public override void BuildAnimalHeader()
        {
            aAnimal.Head = "Kitten's Head has been built";
        }

        public override void BuildAnimalBody()
        {
            aAnimal.Body = "Kitten's Body has been built";
        }

        public override void BuildAnimalLeg()
        {
            aAnimal.Leg = "Kitten's Leg has been built";
        }

        public override void BuildAnimalArm()
        {
            aAnimal.Arm = "Kitten's Arm has been built";
        }

        public override void BuildAnimalTail()
        {
            aAnimal.Tail = "Kitten's Tail has been built";
        }
    }
    public abstract class Animal
    {
        public string Head { get; set; }
        public string Body { get; set; }
        public string Leg { get; set; }
        public string Arm { get; set; }
        public string Tail { get; set; }


        //helper method for demo the Polymorphism, so we can 
        //easily tell what type object it is from client.
        public abstract void Eat();

        //helper method for demo the result from client
        public void ShowMe()
        {
            Console.WriteLine(Head);
            Console.WriteLine(Body);
            Console.WriteLine(Leg);
            Console.WriteLine(Arm);
            Console.WriteLine(Tail);
            Eat();

        }
    }
    public class Monkey : Animal
    {
        //helper method to show monkey's property for demo purpose
        public override void Eat()
        {
            Console.WriteLine("Since I am Monkey, I like to eat banana");
        }
    }
    public class Kitten : Animal
    {
        public override void Eat()
        {
            Console.WriteLine("Since I am Kitten, I like to eat kitten food");
        }
    }
    public class Kid
    {
        public string Name { get; set; }

        //construct process to build an animal object, 
        //after this process completed, a object 
        //will be consider as a ready to use object.
        public void MakeAnimal(AnimalBuilder aAnimalBuilder)
        {
            aAnimalBuilder.BuildAnimalHeader();
            aAnimalBuilder.BuildAnimalBody();
            aAnimalBuilder.BuildAnimalLeg();
            aAnimalBuilder.BuildAnimalArm();
            aAnimalBuilder.BuildAnimalTail();
        }


    }
}

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

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


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

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

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

आप फास्ट फूड रेस्तरां में गए और आप भोजन का आदेश देते हैं।

1) क्या खाना?

पिज़्ज़ा

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

कैप्सिकम, टमाटर, बीबीक्यू चिकन, कोई पिनप्ले नहीं

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

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

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

पिज्जा के रूपों

केवल पनीर, पनीर + टमाटर + कैप्सिकम, पनीर + टमाटर इत्यादि।

कोड नमूना

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


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

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

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

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

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

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


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

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

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


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

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

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

मूल फैक्टरी उदाहरण

// 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


सार फैक्टरी और बिल्डर पैटर्न दोनों रचनात्मक पैटर्न हैं लेकिन विभिन्न इरादों के साथ।

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

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

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

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

वस्तु बनाने के लिए दोनों रचनात्मक पैटर्न हैं।

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.






builder-pattern