क्या यह एक प्रसिद्ध डिजाइन पैटर्न है? इसका नाम क्या है?

Question

मैं अक्सर कोड में यह देखा है, लेकिन जब मैं इसके बारे में बात करते हैं मैं इस तरह के 'नमूना'

के लिए नाम पता नहीं है मेरे पास है कि एक ओवरलोड विधि 3 तर्कों और जानबूझकर है कि कॉल 2 तर्क के साथ एक विधि स्ट्रिंग स्ट्रिंग के लिए तीसरा सेट करता है।

public void DoWork(string name, string phoneNumber) 
{ 
    DoWork(name, phoneNumber, string.Empty) 
} 

private void DoWork(string name, string phoneNumber, string emailAddress) 
{ 
    //do the work 
} 

कारण मैं कर रहा हूँ इस कोड को नकल नहीं करने, और मौजूदा कॉल अभी भी विधि केवल 2 पैरामीटर है कि कॉल करने के लिए अनुमति देने के लिए है।

क्या यह एक पैटर्न है, और क्या इसका नाम है?

Answer 1

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

---

एक अधिक आधिकारिक बोली के लिए, यहाँ प्रभावी जावा 2 संस्करण, से एक अंश है आइटम 2: जब

परंपरागत रूप से कई निर्माता मापदंडों (excerpt online) के साथ सामना एक बिल्डर पैटर्न पर विचार करें, प्रोग्रामर ने टेलीस्कोपिंग कन्स्ट्रक्टर पैटर्न का उपयोग किया है, जिसमें आप केवल आवश्यक पैरामीटर के साथ एक कन्स्ट्रक्टर प्रदान करते हैं, दूसरा एक वैकल्पिक पैरामीटर के साथ, एक तिहाई दो वैकल्पिक पैरामीटर के साथ, और इसलिए पर ...

फिर, आमतौर पर टेलीस्कोपिक पैटर्न पर रचनाकारों के संदर्भ में चर्चा की जाती है (जहां उदा। एक 2-Arg कन्स्ट्रक्टर के पास 3-arg constructor इत्यादि का आह्वान करने के लिए एक पंक्ति this(arg1, arg2, ARG3_DEFAULT); होगी), लेकिन मुझे नहीं लगता कि इसे अन्य विधियों के लिए सामान्यीकृत क्यों नहीं किया जा सकता है।

---

एक और आधिकारिक बोली, दुर्भाग्य से पैटर्न का कोई परिभाषा के साथ: Sun Developer Network: How to Write Doc Comments for the Javadoc Tool:

सूचना तरीके और कंस्ट्रक्टर "telescoping" आदेश है, जो पहली "कोई आर्ग" फ़ॉर्म का मतलब है में हैं, तो "1 तर्क" फ़ॉर्म, फिर "2 तर्क" फ़ॉर्म, और बहुत आगे।

---

और एक और यादृच्छिक उद्धरण, पैटर्न का एक और अधिक स्पष्ट परिभाषा के साथ: I Am Hate Method Overloading (And So Can You!):

Telescoping तरीके

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

यह अंतिम उद्धरण सीधे प्रस्तावित करता है कि डिफ़ॉल्ट तर्कों के लिए भाषा समर्थन एक बेहतर विकल्प है।

Answer 2

के नाम अधिक भार है और यह एक डिजाइन पैटर्न, लेकिन एक OOP सुविधा

http://en.wikipedia.org/wiki/Method_overloading

Answer 3

मेरा अनुमान है कि या तो अपने DoWork तरीकों CreateContact बुलाया जाना चाहिए या CreateContact करने के लिए अपने कॉल DoWork होना चाहिए नहीं है। ..

लेकिन यह वास्तव में एक पैटर्न नहीं है। यह method overloading का एक आम उपयोग है।

Answer 4

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

रूबी की तरह आप के रूप में ऐसी ही कुछ कर सकता है एक भाषा में इस प्रकार

def dowork(name, phoneNumber, emailAddress = '') 
    # code here 
    end 

Answer 5

मैं कहना चाहता हूँ यह बहुत ज्यादा एक ग # < 4 डिफ़ॉल्ट तर्क की कमी के लिए चारों ओर काम है। यदि आप 'पैटर्न में गायब हैं, तो भाषा की विशेषताएं गायब हैं' विचार के स्कूल मुझे लगता है कि आप इसे एक पैटर्न कह सकते हैं, हालांकि आमतौर पर नामित नहीं किया जाता है।

संपादित करें: ठीक है आपके अपडेट ने मुझे वास्तव में फेंक दिया है, मुझे नहीं लगता कि आप एक निजी विधि को बुलाते हुए सार्वजनिक विधि के साथ क्या करने का प्रयास कर रहे हैं। जहां तक ​​सार्वजनिक एपीआई का संबंध है, आप बस सभी निजी विधियों कोड को सार्वजनिक विधि में स्थानांतरित कर सकते हैं और 'डिफ़ॉल्ट' मान के लिए स्थानीय चर हो सकते हैं। या दोनों विधियों को कक्षा में अन्य स्थानों से भी बुलाया जाता है?

Answer 6

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

Answer 7

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

Answer 8

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

- (id)init { 
    return [self initWithParam:0]; 
} 

- (id)initWithParam:(int)param { 
    // Do real initialization here! 
    return self; 
}