बिल्डर पैटर्न और टेम्पलेट विधि (बिल्डर बनाम टेम्पलेट) के बीच मतभेद

Question

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

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

उपर्युक्त अंतर के अलावा, क्या कोई अन्य अंतर है?

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

क्या कोई स्पष्टीकरण दे सकता है। धन्यवाद।

मैं http://www.dofactory.com/Patterns/Patterns.aspx

Answer 1

खाका विधि जिक्र कर रहा हूँ वास्तव में कुछ तरीकों कि प्रत्येक उपवर्ग को परिभाषित करना होगा परिभाषित करने के लिए सिर्फ एक तरीका है।

बिल्डर पैटर्न का उपयोग एक और जटिल वस्तु बनाने के लिए किया जाता है।

आइए कहें कि हम विभिन्न साब (कार ब्रांड) मॉडल बनाना चाहते हैं। प्रत्येक मॉडल में विभिन्न इंजन, रोशनी आदि होते हैं

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

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

Answer 2

मुझे एक ही प्रश्न बहुत दिलचस्प मिला।

साब कार उदाहरण दिलचस्प है लेकिन यह "गैंग ऑफ फोर" (डिजाइन पैटर्न) में बिल्डर पैटर्न के विवरण का पालन नहीं करता है।

मैं "गैंग ऑफ चार" शब्दावली का उपयोग करूँगा।

गैंग ऑफ चार में, aDirector->Construct() के प्रत्येक आमंत्रण के लिए ठोस बिल्डरों का मिश्रण नहीं हो सकता है, इसलिए साब उदाहरण, जबकि दिलचस्प है, वास्तव में मेरे लिए सवाल का जवाब नहीं देता है।

बिल्डर पदानुक्रम से निर्देशक वस्तु की जुदाई एक महत्वपूर्ण अंतर है:

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

इसके अतिरिक्त, यदि आप विरासत द्वारा निदेशक वस्तु पर विस्तार करना चाहते हैं तो आप अपने पदानुक्रम को गुणा किए बिना ऐसा कर सकते हैं। उदाहरण के लिए, आपके पास अंतिम निर्माण से पहले समय बचाने के लिए भवन की एक स्पष्ट प्रक्रिया हो सकती है - आप अपने कंक्रीट बिल्डरों को फिर से लागू करने के बिना विरासत द्वारा इसे अनुकूलित करने के लिए निदेशक वस्तु को उपclass कर सकते हैं या यहां तक ​​कि "टेम्पलेट विधि" का उपयोग भी कर सकते हैं।

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

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

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

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

तो सवाल बन जाता है - अगर आप बिल्डर और खाका फैक्टरी में कोई अंतर नहीं देखते हैं - इन सवालों के जवाब देने की कोशिश:

1. आप प्रणाली के उस विशेष हिस्से पर होने पसंद करते हैं क्या परिप्रेक्ष्य? क्या यह "व्यवहार" या "सृजन" है? और

2. क्या आपको मजबूत encapsulation, या गतिशील प्रतिस्थापन या तैनाती या एक निर्माता उदाहरण के tweaking की आवश्यकता है, या आप जटिलता की प्रक्रिया (विरासत, संरचना, या अन्यथा) निर्माण प्रक्रिया के आसपास विकसित करने की उम्मीद है या टेम्पलेट विधि? यदि इनमें से किसी भी प्रश्न का उत्तर बिल्डर/रणनीति संरचना के साथ जाता है। अन्यथा, एक्सएक्स विधि पैटर्न में संबंध या व्यवहार के सरल polymorphysm का उपयोग करें।

Answer 3

इससे पहले कि मैं शुरू करते हैं, अपने सभी उत्तरों के लिए मेरी सार्वभौमिक लाइन: "किसी भी भाषा में किसी भी प्रोग्रामिंग अवधारणा को तीन तरह से समझने के लिए (ख) रनटाइम परिप्रेक्ष्य (ग) मेमोरी दृष्टिकोण से (a) डिजाइन दृष्टिकोण से।

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

मेरी समझ में है .net में हमारे पास नियंत्रकबिल्डर है, एसक्यूएलकनेक्शनस्ट्रिंगबिल्डर, उरीबिल्डर; सभी नियंत्रक फैक्टरी, एसक्यूएल, उरी कारखानों को अनुकूलित कर रहे हैं; तो मेरा मुख्य कार्यक्रम नियंत्रकों, ConnStrings, उरीज उत्पन्न करने के लिए उन कारखानों का उपयोग कर सकते हैं। तो बिल्डर पैटर्न फैक्टरी सेटअप अनुकूलन के लिए है? क्या हमें फैक्टरी सेटअप अनुकूलन की आवश्यकता है? शायद कभी नहीं; इसके बजाय मैं सबसे अच्छा करूँगा 4 एसिंक विधियों का निर्माण कर रहा हूं और उन्हें चरण 2 पैरामीटर (दूसरे चेनिंग चरण 3 पैरामीटर ...) के साथ श्रृंखलाबद्ध कर सकता हूं। क्या abt टेम्पलेट पैटर्न (asp.net वर्कफ़्लो टेम्पलेट या jQuery टेम्पलेट या डिब्बाबंद टेम्पलेट)। मेरे लिए दोनों समान हैं लेकिन बिल्डर की तुलना में, टेम्पलेट प्रकृति में अधिक कठोर है (लगभग सभी निश्चित, कुछ विशिष्ट गुणों को एक विशिष्ट tmplt को परिभाषित करने के लिए बदल रहे हैं) और एक बार टेम्पलेट को कारखाने परिभाषित किया जाता है। मैंने इन दोनों के लिए एक और अफवाह भी देखी है, "कोई फैक्टरी-> कोई भी उत्पाद" When would you use the Builder Pattern? के रूप में सक्षम है; लेकिन यह सच नहीं है कि यह से ऊपर है। नेट कंट्रोलरबिल्डर, एसक्यूएल, यूरी परिदृश्य "कारखाने की फैक्टरी" अवधारणा के साथ। जो कई डिजाइन प्रिंसिपल (एसआरपी, एलएसपी, खराब encapsulation) के खिलाफ है। आशा है कि इन दोनों के बारे में मेरा पूरा लेखन शुरुआती से उन्नत तक मदद करेगा।