क्या मुझे ओवरलोडेड विधियों पर विभिन्न रिटर्न प्रकारों का उपयोग करना चाहिए?

Question

ओवरलोडेड विधियों पर विभिन्न रिटर्न प्रकारों को वापस करने पर कोई सर्वोत्तम प्रथा है? उदाहरण के लिए यदि मेरे पास मेरे डीएएल में लोड विधि है, तो मैं या तो एक आइटम या वस्तुओं का एक गुच्छा लोड करना चाहता हूं। मुझे पता है कि मैं दृष्टिकोण के एक नंबर इस्तेमाल कर सकते हैं:

लोड एक वस्तु

MyBusinessObject LoadOne(int id) 
{ 
} 

लोड से अधिक ऑब्जेक्ट

MyBusinessObject[] LoadMany(params int[] ids) 
{ 
} 

अब कुछ मैं जानता हूँ कि मैं कर सकते हैं कर एक विधि ओवरलोड है और विभिन्न वापसी प्रकार हैं। इसलिए जैसा:

MyBusinessObject Load(int id) 
{ 
} 

और

MyBusinessObject[] Load(params int[] ids) 
{ 
} 

जबकि ऐसा लगता है मुझे ऐसा करने को रोकने के लिए कुछ नहीं है, और यह एक API नजरिए से चीजों को स्वच्छ रखता है, यह एक अच्छा विचार की तरह लग रहा है? मैं कल रात भर आया और मेरा हिस्सा सोचता है कि मुझे ओवरलोडेड विधि के लिए मिलान प्रकारों को मिलान करने के कारण के लिए ऐसा नहीं करना चाहिए।

मेरे पास लोड (int आईडी) विधि भी एक संग्रह लौटा सकती है जिसमें केवल एक आइटम होता है। ऐसा लगता है कि यह कम से कम आश्चर्य के सिद्धांत का उल्लंघन करता है, हालांकि यदि आप एक आइटम लौटने की उम्मीद कर रहे हैं, तो आपको उस आइटम को वापस करना चाहिए, आपको एक आइटम वाली सूची वापस नहीं करनी चाहिए।

तो यहाँ अपने विरोधी इन विचारों को आसपास के विचार कर रहे हैं:

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

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

क्या इस अभ्यास के आसपास कोई सर्वोत्तम अभ्यास है? मुझे इस विषय पर दूसरों के विचारों को सुनने में दिलचस्पी होगी।

Answer 1

मैं नाम में एपीआई स्पष्ट और उपयोग बहुलता बनाने के लिए परीक्षा हो सकता है:

Customer LoadCustomer(int id) {...} 
Customer[] LoadCustomers(params int[] id) {...} 

वास्तव में, params यहां शायद ही कभी उपयोगी है - आप आमतौर पर संकलन समय पर आईडी पता नहीं है।

Answer 2

मेरा व्यक्तिगत विचार यह है कि बाद की विधि एपीआई-उपयोगकर्ता परिप्रेक्ष्य से अधिक समझ में आता है।

Answer 3

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

Answer 4

मैं की आपकी सूची में पहले बिंदु का पालन करता हूं "विचार इस विचार को कम करते हैं" कहता है "ओवरलोड को एक ही प्रकार वापस करना चाहिए"।

लेकिन फिर आप कुछ अलग परिदृश्यों के साथ "लोडमेन" को अधिभारित कर सकते हैं;

public Customer Load(int id) 
{ 
    // return just one customer 
} 

public List<Customer> LoadMany() 
{ 
    // return every single customer 
} 

public List<Customer> LoadMany(int statusFilter) 
{ 
    // return a filtered list of customers 
} 

public List<Customer> LoadMany(DateTime InitialContactFrom) 
{ 
    // return a filtered list of customers 
} 

public List<Customer> LoadMany(DateTime InitialContactFrom, DateTime InitialContactBefore) 
{ 
    // return a filtered list of customers 
} 

... जो कुछ भी संयोजन आप की जरूरत स्पष्ट रूप से जोड़ा जा सकता है लेकिन अंत में, LoadMany सूची लौटाता है और लोड एक इकाई देता है।

Answer 5

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

उदाहरण के लिए:

var a = MyFunc("Some text"); 

और

var a = MyFunc(1); 

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