क्या नामांकित तर्क बिल्डर पैटर्न को प्रतिस्थापित करते हैं?

20

नाम और वैकल्पिक तर्कों का समर्थन करने वाली भाषा का उपयोग करते समय, क्या बिल्डर पैटर्न का व्यावहारिक उपयोग नहीं होता है?

बिल्डर:

new Builder(requiredA, requiredB).setOptionalA("optional").Build();

वैकल्पिक / नामित तर्क:

new Object(requiredA, requiredB, optionalA: "optional");

design-patterns builder-pattern

— पॉल निकोविक्ज़
स्रोत

3

आप 20 वैकल्पिक तर्क कैसे संभालते हैं? एक समस्या यह नहीं है कि बिल्डर को बड़े होने तक हल करने की आवश्यकता है। आपके द्वारा यहाँ वर्णित बिंदु पर आपको दो निर्माणकर्ता मिल गए हैं (और मैं उस समस्या के लिए बिल्डर का निर्माण नहीं करूँगा)।

1

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

— थॉमस जंक

21

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

मेरे सिर के ऊपर से, मैं सोच सकता हूं कि कोई व्यक्ति इस तरह से एक 3 डी गेम में वस्तुओं का "निर्माण" करना चाहता है:

// Just ignore the fact that this hypothetical god class is coupled to everything ever
new ObjectBuilder(x, y, z).importBlenderMesh("./meshes/foo")
                          .syncWithOtherPlayers(serverIP)
                          .compileShaders("./shaders/foo.vert", "./shaders/foo.frag")
                          .makeDestructibleRigidBody(health, weight)
                          ...

मैं यह तर्क दूंगा कि यह बिल्डर तरीकों के साथ अधिक पठनीय है जिसे मैंने अभी वैकल्पिक मापदंडों के साथ बनाया है।

new Object(x, y, z, meshType: MESH.BLENDER,
                    meshPath: "./meshes/foo",
                    serverToSyncWith: serverIP,
                    vertexShader: "./shaders/foo.vert",
                    physicsType: PHYSICS_ENGINE.RIGID_DESTRUCTIBLE,
                    health: health,
                    weight: weight)
                    ...

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

बेशक, यदि आपकी वस्तु के निर्माण में केवल एक से पांच तर्क लगते हैं, तो बिल्डर पैटर्न को शामिल करने की कोई आवश्यकता नहीं है, चाहे आपने नाम / वैकल्पिक पैरामीटर का उपयोग किया हो या नहीं।

— Ixrec
स्रोत

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

— user949300

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

— जूल्स

1

यदि वैकल्पिक मापदंडों में से एक नहीं है (शरीर: नया विनाशकारी रिगिडबॉडी (स्वास्थ्य, वजन), ...)

— वेयलैंड यूटानी

@Jules। वेयलैंड ने क्या कहा - वजन और ऊंचाई के लिए एक अच्छी तरह से नामित कंस्ट्रक्टर बनाएं।

— user949300

8

Ixrec ने जो कहा, इसके अलावा, पैरामीटर या नामांकित विधि आपको किसी भी निर्माण की स्थिति में अपनी वस्तु रखने की अनुमति नहीं देगी जिसमें इसे बनाने से पहले इसे अभी भी संशोधित किया जा सकता है। यह बिल्डर की सुंदरता है, जहां आप इसके निर्माण के कुछ हिस्सों को अलग-अलग तरीकों या कक्षाओं में रख सकते हैं:

var myThingBuilder = new ThingBuilder("table");
myThingBuilder.setAttribute(Attributes.Legs, 4);

inventoryManager.setPrices(myThingBuilder);

// inventory manager
var availableCheapestMaterial = getMaterial();
myThingBuilder.setMaterial(availableCheapestMaterial);

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

— अल्फा
स्रोत

मैं आपके अंतिम पैराग्राफ को नहीं समझता। यदि आप "तैयार होने तक अपने बिल्डर को सिस्टम के चारों ओर फेंक देते हैं", तो उसे सिस्टम का बहुत अधिक ज्ञान है। आपका ThingBuilder Attributes के बारे में जानता है, रहस्यमय तरीके से InventoryManager द्वारा संशोधित किया गया है, और सामग्री के बारे में जानता है। यह मत देखो कि ज्ञान कैसे घट रहा है।

— user949300

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

— अल्फा

1

यह इस बात पर निर्भर करता है कि आप बिल्डर के साथ क्या कर रहे हैं।

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

बिल्डर को प्रतिस्थापित करने पर आपके पास पठनीयता / उपयोग ट्रेडऑफ़ हो सकती है जो @Ixrec मेंटीनेंस (या नहीं हो सकता है), यह इस बात पर निर्भर करता है कि आप बिल्डर के साथ क्या कर रहे हैं)।

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

MockBuilder एक उदाहरण है जहां इसे नामांकित पारम के साथ प्रतिस्थापित नहीं किया जा सकता है। पृष्ठ से:

— rvazquezglez
स्रोत

-5

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

— codedabbler
स्रोत

3

हाँ, बिल्डर्स जटिल अपरिवर्तनीय वस्तुओं के साथ काम करने के लिए महान हैं (या यहां तक कि उत्परिवर्ती वाले - आपको यह सुनिश्चित करने की आवश्यकता है कि ऑब्जेक्ट का उपयोग करने से पहले एक सुसंगत स्थिति में है)। जिसके अनुसार, new Integer(42), new BigDecimal("42.000")और new String("foobar")immutables कि ... अच्छी तरह से, एक बिल्डर इन उदाहरणों के लिए बेकार में जटिल हो जाएगा करने के लिए सभी निर्माता ये हैं। तो एक बिल्डर अपरिवर्तनीय के साथ काम करने के लिए आवश्यक नहीं है जब निर्माणकर्ता बस काम कर सकते हैं।

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

— कोडेडेब्लर

2

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