एक प्रकार को इसके बिल्डर के साथ क्यों जोड़ा जाएगा?

20

मैंने हाल ही में कोड रिव्यू पर मेरा एक जावा उत्तर हटा दिया है , जो इस तरह शुरू हुआ है:

private Person(PersonBuilder builder) {
रूक जा। लाल झंडा। एक व्यक्ति निर्माण एक व्यक्ति का निर्माण करेगा; यह एक व्यक्ति के बारे में जानता है। व्यक्ति वर्ग को किसी व्यक्ति-कर्मचारी के बारे में कुछ नहीं जानना चाहिए - यह सिर्फ एक अपरिवर्तनीय प्रकार है। आपने यहां एक परिपत्र युग्मन बनाया है, जहां A, B पर निर्भर करता है, जो A पर निर्भर करता है।

व्यक्ति को बस इसके मापदंडों का सेवन करना चाहिए; एक ग्राहक जो निर्माण के बिना एक व्यक्ति बनाने के लिए तैयार है उसे ऐसा करने में सक्षम होना चाहिए।

मुझे एक अपमान के साथ थप्पड़ मारा गया, और बताया कि (उद्धृत करते हुए) लाल झंडा, क्यों? यहाँ कार्यान्वयन का वही आकार है जो जोशुआ बलोच ने अपनी "प्रभावी जावा" पुस्तक (आइटम # 2) में प्रदर्शित किया था।

तो, ऐसा प्रतीत होता है कि जावा में बिल्डर पैटर्न को लागू करने का वन राइट तरीका बिल्डर को नेस्टेड प्रकार बनाना है (यह ऐसा नहीं है कि यह सवाल हालांकि के बारे में है), और फिर उत्पाद बनाएं (ऑब्जेक्ट का वर्ग बनाया जा रहा है) ) बिल्डर पर निर्भरता लें , जैसे:

private StreetMap(Builder builder) {
    // Required parameters
    origin      = builder.origin;
    destination = builder.destination;

    // Optional parameters
    waterColor         = builder.waterColor;
    landColor          = builder.landColor;
    highTrafficColor   = builder.highTrafficColor;
    mediumTrafficColor = builder.mediumTrafficColor;
    lowTrafficColor    = builder.lowTrafficColor;
}

_{^{https://en.wikipedia.org/wiki/Builder_pattern#Java_example}}

समान बिल्डर पैटर्न के लिए एक ही विकिपीडिया पृष्ठ में C # के लिए एक बेतहाशा अलग (और अधिक लचीला) कार्यान्वयन है।

//Represents a product created by the builder
public class Car
{
    public Car()
    {
    }

    public int Wheels { get; set; }

    public string Colour { get; set; }
}

जैसा कि आप देख सकते हैं, यहां उत्पाद को एक Builderवर्ग के बारे में कुछ भी नहीं पता है , और सभी के लिए यह एक प्रत्यक्ष निर्माता कॉल, एक अमूर्त कारखाना, ... या एक बिल्डर द्वारा त्वरित किया जा सकता है - जहां तक मैं इसे समझता हूं, एक रचनात्मक पैटर्न के उत्पाद को कभी भी इस बारे में कुछ भी जानने की जरूरत नहीं है कि इसे क्या बनाया जा रहा है।

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

तो सौदा क्या है? क्यों एक समस्या है कि पहली जगह में भी मौजूद नहीं होना चाहिए पर अधिक इंजीनियर समाधान के साथ आते हैं ? यदि हम जोशुआ बलोच को एक मिनट के लिए अपने पदचिन्ह से निकालते हैं, तो क्या हम एक ठोस, दो ठोस प्रकारों को युग्मित करने और इसे एक सर्वोत्तम अभ्यास कहने के लिए एक अच्छा, वैध कारण लेकर आ सकते हैं?

यह सब मेरे लिए कार्गो-पंथ प्रोग्रामिंग का पुनरावर्तन है ।

— मैथ्यू गुइंडन
स्रोत

12

और यह "सवाल" सिर्फ एक शेख़ी के रूप में फिर से आता है ...

— फिलिप केंडल

2

@PhilipKendall शायद थोड़ा। लेकिन मैं वास्तव में यह समझने में दिलचस्पी रखता हूं कि प्रत्येक जावा बिल्डर कार्यान्वयन में उस तंग युग्मन क्यों है।

— मथिउ गुइंडन

19

@PhilipKendall यह मेरे लिए जिज्ञासा का प्रतीक है।

— मस्त

8

@PhilipKendall यह एक शेख़ी की तरह पढ़ता है, हाँ, लेकिन इसके मूल में एक वैध विषय है। शायद शेख़ी को संपादित किया जा सकता है?

— एंड्रेस एफ

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

— रॉबर्ट हार्वे

22

मैं आपके दावे से असहमत हूं कि यह लाल झंडा है। काउंटरपॉइंट के आपके प्रतिनिधित्व से मैं भी असहमत हूं, कि बिल्डर पैटर्न का प्रतिनिधित्व करने का एक सही तरीका है।

मेरे लिए एक सवाल है: क्या बिल्डर टाइप के एपीआई का एक आवश्यक हिस्सा है? यहाँ, पर्सब्युलेर व्यक्ति एपीआई का एक आवश्यक हिस्सा है?

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

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

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

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

— जेफ बोमैन मोनिका का समर्थन करते हैं
स्रोत

मुझे लगता है कि मैं कंस्ट्रक्टर को एक कार्यान्वयन विवरण के रूप में मानने के बारे में आपकी बात देखता हूं। ऐसा नहीं लगता है कि प्रभावी जावा इस संदेश को ठीक से बताता है (फिर मैंने उस पुस्तक को नहीं पढ़ा है / नहीं है), जूनियर के एक टन (?) को छोड़कर जावा देवों का मानना है कि "यह कैसे किया जाता है" सामान्य ज्ञान की परवाह किए बिना। । मैं मानता हूं कि विकिपीडिया के उदाहरण तुलना के लिए खराब हैं .. लेकिन हे विकिपीडिया .. और एफडब्ल्यूआईडब्ल्यू मैं वास्तव में गिरावट की परवाह नहीं करता; हटाए गए उत्तर वैसे भी एक सकारात्मक शुद्ध स्कोर के साथ बैठे हैं (और अंत में एक [बैज: सहकर्मी-दबाव] स्कोर करने का मेरा मौका जाता है)।

— मैथ्यू गुइंडन

1

फिर भी, मैं इस विचार को नहीं हिला सकता हूं कि बहुत सारे निर्माता तर्कों के साथ एक प्रकार एक डिजाइन मुद्दा है (एसआरपी को तोड़ने की बदबू आ रही है), कि एक बिल्डर पैटर्न एक कालीन के नीचे तेजी से चमकता है।

— मैथ्यू गुइंडन

3

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

— जेफ बोमेन ने मोनिका का

1

काफी उचित। मुझे अभी भी String(StringBuilder)कंस्ट्रक्टर नहीं मिला है , जो उस "सिद्धांत" का पालन करता है, जहां यह एक प्रकार के लिए सामान्य है कि उसके बिल्डर पर निर्भरता हो। जब मैंने उस कंस्ट्रक्टर को ओवरलोड देखा तो मैं भड़क गया। यह String42 निर्माण मापदंडों की तरह नहीं है ...

— मैथ्यू गुइंडन

3

@ लालन ओड। मैंने वस्तुतः इसका उपयोग कभी नहीं देखा है और यह नहीं जानता कि यह अस्तित्व में है; toString()सार्वभौमिक है।

— क्राइसिस -ऑन स्ट्राइक-

7

मैं समझता हूं कि जब एक बहस में 'अथॉरिटी की अपील' का इस्तेमाल किया जाता है तो यह कितना कष्टप्रद हो सकता है। तर्क अपने स्वयं के IMO पर खड़े होने चाहिए और हालांकि इस तरह के एक सम्मानित व्यक्ति की सलाह को इंगित करना गलत नहीं है, यह वास्तव में अपने आप में एक पूर्ण तर्क नहीं माना जा सकता है क्योंकि हम जानते हैं कि सूर्य पृथ्वी के चारों ओर यात्रा करता है क्योंकि अरस्तू ने ऐसा कहा था ।

ऐसा कहने के बाद, मुझे लगता है कि आपके तर्क का आधार उसी तरह का है। हमें कभी भी दो ठोस प्रकारों को युग्मित नहीं करना चाहिए और इसे एक सर्वोत्तम अभ्यास कहना चाहिए क्योंकि ... किसी ने ऐसा कहा?

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

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

— JimmyJames
स्रोत

तो ... उच्च युग्मन, कम सामंजस्य => सुखद अंत? हम्म ... मैं बिल्डर के बारे में बिंदु "कंस्ट्रक्टर का विस्तार" देख रहा हूं, लेकिन एक और उदाहरण सामने लाने के लिए, मैं यह देखने में नाकाम हूं कि Stringएक कंस्ट्रक्टर ओवरलोड के साथ क्या कर रहा है जो एक StringBuilderपैरामीटर ले रहा है (हालांकि यह बहस योग्य है कि क्या StringBuilderएक बिल्डर है , लेकिन वह है दूसरी कहानी)।

— मैथ्यू गुइंडन

4

@ MatMug स्पष्ट होने के लिए, मुझे वास्तव में इस तरह से एक मजबूत भावना नहीं है। मैं बिल्डर पैटर्न का उपयोग नहीं कर रहा हूं क्योंकि मैं वास्तव में ऐसी कक्षाएं नहीं बनाता हूं जिनमें बहुत सारे राज्य इनपुट हैं। मैं आम तौर पर ऐसे वर्ग को उन कारणों से विघटित कर दूंगा जिनके कारण आप कहीं और करते हैं। मैं केवल इतना कह रहा हूं कि यदि आप यह दिखा सकते हैं कि यह दृष्टिकोण कैसे समस्या का कारण बनता है, तो इससे कोई फर्क नहीं पड़ेगा कि भगवान नीचे आए और उस बिल्डर पैटर्न को एक पत्थर की गोली पर मूसा को सौंप दिया। तुम जीते'। दूसरी ओर यदि आप नहीं कर सकते हैं ...

— जिमीजैम

बिल्डर पैटर्न का एक वैध उपयोग जो मुझे अपने कोड बेस में मिला है, VBIDE एपीआई का मजाक उड़ाने के लिए है; मूल रूप से आप एक कोड मॉड्यूल की स्ट्रिंग सामग्री की आपूर्ति करते हैं, और बिल्डर आपको एक VBEनकली देता है , जो विंडोज़, सक्रिय कोड फलक, एक परियोजना और एक मॉड्यूल के साथ एक घटक होता है जिसमें आपके द्वारा प्रदान की गई स्ट्रिंग होती है। इसके बिना, मुझे नहीं पता कि मैं रबरडक में 80% परीक्षण कैसे लिख पाऊंगा , कम से कम खुद को हर बार जब भी मैं उन्हें देखता हूं, आंख में छुरा घोंपकर।

— मथिउ गुइंडन

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

— जिमीजैम

4

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

बड़ी संख्या में पैरामीटर होने के कारण आपको बिल्डर का उपयोग कैसे करना चाहिए? खैर, बड़ी संख्या में पैरामीटर होना वास्तविक दुनिया में असामान्य नहीं है, न ही यह एकल जिम्मेदारी सिद्धांत का उल्लंघन करता है। यह तब भी बेकार है जब आपके पास दस स्ट्रिंग पैरामीटर हैं और यह याद रखने की कोशिश कर रहे हैं कि कौन से हैं और यह पांचवां या छठा स्ट्रिंग है या नहीं, जो अशक्त होना चाहिए। एक बिल्डर मापदंडों को प्रबंधित करना आसान बनाता है और यह अन्य शांत चीजें भी कर सकता है जिनके बारे में जानने के लिए आपको पुस्तक को पढ़ना चाहिए।

आप एक ऐसे बिल्डर का उपयोग कब करते हैं जो इसके प्रकार के साथ युग्मित नहीं है? आम तौर पर जब किसी वस्तु के घटक तुरंत उपलब्ध नहीं होते हैं और जिन वस्तुओं के टुकड़े होते हैं, उन्हें उस प्रकार के बारे में जानने की आवश्यकता नहीं होती है जिसे आप बनाने की कोशिश कर रहे हैं या आप उस वर्ग के लिए एक बिल्डर जोड़ रहे हैं जिस पर आपका नियंत्रण नहीं है। ।

— पुराना मोटा नेड
स्रोत

अजीब, एक ही समय में मुझे एक बिल्डर की आवश्यकता थी जब मेरे पास एक प्रकार था जिसमें एक निश्चित आकार नहीं होता है, जैसे कि यह MockVbeBuilder , जो आईडीई के एपीआई का एक नकली बनाता है; एक परीक्षण के लिए बस एक सरल कोड मॉड्यूल की आवश्यकता हो सकती है, दूसरे परीक्षण के लिए दो रूपों और एक वर्ग मॉड्यूल की आवश्यकता हो सकती है - IMO जो कि GoF का बिल्डर पैटर्न है। उस ने कहा, मैं एक पागल निर्माता के साथ दूसरे वर्ग के लिए इसका इस्तेमाल करना शुरू कर सकता हूं ... लेकिन युग्मन अभी बिल्कुल भी ठीक नहीं लगता है।

— मैथ्यू गुइंडन

1

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

— ओल्ड फैट नेड

1

एक रचनात्मक पैटर्न के उत्पाद को कभी भी इस बारे में कुछ भी जानने की आवश्यकता नहीं है कि इसे क्या बनाया जा रहा है।

Personवर्ग क्या इसे बनाने है पता नहीं है। इसमें केवल एक पैरामीटर के साथ एक कंस्ट्रक्टर है, तो क्या? पैरामीटर के प्रकार का नाम समाप्त होता है ... बिल्डर जो वास्तव में कुछ भी मजबूर नहीं करता है। यह सिर्फ एक नाम है।

बिल्डर एक महिमा ¹ कॉन्फ़िगरेशन ऑब्जेक्ट है। और एक विन्यास वस्तु वास्तव में सिर्फ एक साथ गुणों को समूहीकृत कर रही है जो एक दूसरे से संबंधित हैं। यदि वे केवल एक वर्ग के निर्माणकर्ता को पारित होने के उद्देश्य से एक-दूसरे से संबंधित हैं, तो ऐसा ही हो! दोनों originऔर destinationके StreetMapउदाहरण प्रकार के होते हैं Point। क्या मानचित्र के प्रत्येक बिंदु के व्यक्तिगत निर्देशांक को पास करना संभव होगा? ज़रूर, लेकिन एक Pointसाथ के गुण , साथ ही आप उन पर सभी प्रकार के तरीके रख सकते हैं जो उनके निर्माण में मदद करते हैं:

¹ अंतर यह है कि बिल्डर सिर्फ एक सादे डेटा ऑब्जेक्ट नहीं है, लेकिन इन जंजीर सेटर कॉल के लिए अनुमति देता है। ज्यादातर कैसे खुद का निर्माण करने के साथ संबंध है।Builder

अब मिश्रण में थोड़ा सा कमांड पैटर्न जोड़ते हैं , क्योंकि यदि आप बारीकी से देखते हैं, तो बिल्डर वास्तव में एक कमांड है:

यह एक क्रिया को एनकैप्सुलेट करता है: किसी अन्य वर्ग की एक विधि को कॉल करना
यह उस क्रिया को करने के लिए आवश्यक जानकारी रखता है: विधि के मापदंडों के लिए मूल्य

बिल्डर के लिए विशेष भाग यह है कि:

कहा जाने वाला वह तरीका वास्तव में एक वर्ग का निर्माता है। बेहतर अब इसे एक रचनात्मक पैटर्न कहते हैं।
पैरामीटर के लिए मूल्य बिल्डर ही है

Personकंस्ट्रक्टर को जो दिया जा रहा है, वह उसे बना सकता है, लेकिन यह जरूरी नहीं है। यह एक सादा पुराना कॉन्फ़िगरेशन ऑब्जेक्ट या बिल्डर हो सकता है।

— शून्य
स्रोत

0

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

— DeadMG
स्रोत

4

धन्यवाद ... मुझे यकीन है कि यह उत्तर अधिक वोट एकत्र करेगा यदि यह थोड़ा अधिक विस्तारित होता है, तो यह अपूर्ण उत्तर की तरह दिखता है =)

— मैथ्यू गुइंडन

हां, I +1, बिल्डर के लिए एक वैकल्पिक दृष्टिकोण जो युग्मन के बिना समान सुरक्षा उपायों और गारंटियों को प्रदान करता है

— मैट विदाई

3

इसके लिए एक काउंटरपॉइंट के लिए, स्वीकृत उत्तर देखें , जिसमें उन मामलों का उल्लेख है जहां PersonBuilderवास्तव में Personएपीआई का एक अनिवार्य हिस्सा है । जैसा कि यह खड़ा है, यह जवाब इसके मामले में बहस नहीं करता है।

— एंड्रेस एफ