क्या रिटर्निंग IList <T> T [] या सूची <T> लौटने से भी बदतर है?

Question

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

public static IList<int> ExposeArrayIList()
{
    return new[] { 1, 2, 3 };
}

public static IList<int> ExposeListIList()
{
    return new List<int> { 1, 2, 3 };
}

और मेरे परीक्षण कार्यक्रम में उनका उपयोग करें:

static void Main(string[] args)
{
    IList<int> arrayIList = ExposeArrayIList();
    IList<int> listIList = ExposeListIList();

    //Will give a runtime error
    arrayIList.Add(10);
    //Runs perfectly
    listIList.Add(10);
}

दोनों मामलों में जब मैं एक नया मूल्य जोड़ने की कोशिश करता हूं, तो मेरा संकलक मुझे कोई त्रुटि नहीं देता है, लेकिन जाहिर है कि विधि जो मेरे सरणी को उजागर करती IList<T>है एक रनटाइम त्रुटि देती है जब मैं इसमें कुछ जोड़ने की कोशिश करता हूं। लोग हैं, जो नहीं जानता कि मेरी विधि में हो रहा है, और है यह करने के लिए मान जोड़ने के लिए तो, करने के लिए मजबूर कर रहे हैं पहले मेरी नकल IListएक करने के लिए Listत्रुटियों का जोखिम लिए बिना मान जोड़ने के लिए सक्षम होने के लिए। बेशक वे यह देखने के लिए टाइपकास्ट कर सकते हैं कि वे एक Listया एक के साथ काम कर रहे हैं Array, लेकिन अगर वे ऐसा नहीं करते हैं, और वे संग्रह में आइटम जोड़ना चाहते हैं, तो उनके पास कॉपी करने के IListलिए कोई अन्य विकल्प नहीं है List, भले ही यह पहले से ही एक हैList । क्या किसी सरणी को कभी उजागर नहीं किया जाना चाहिए IList?

मेरी एक और चिंता लिंक किए गए प्रश्न (जोर मेरा) के स्वीकृत उत्तर पर आधारित है :

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

यदि आप इसे आंतरिक रूप से उपयोग कर रहे हैं, तो आप इतना ध्यान नहीं दे सकते हैं, और सूची का उपयोग करना ठीक हो सकता है।

कल्पना कीजिए कि किसी ने वास्तव में मेरे द्वारा उपयोग की IList<T>गई ExposeListIlist()विधि को मानों को जोड़ने / हटाने के लिए मेरे तरीके से उपयोग किया है । सब कुछ ठीक काम करता है। लेकिन अब जैसे उत्तर का सुझाव देता है, क्योंकि एक इंटरफ़ेस वापस करना अधिक लचीला है मैं एक सूची के बजाय एक सरणी लौटाता हूं (मेरी तरफ कोई समस्या नहीं!), फिर वे एक इलाज के लिए हैं ...

TLDR:

1) एक इंटरफ़ेस को एक्सपोज़ करने से अनावश्यक कास्ट होती है? क्या इससे कोई फर्क नहीं पड़ता?

2) कभी-कभी यदि लाइब्रेरी के उपयोगकर्ता किसी कास्ट का उपयोग नहीं करते हैं, तो जब आप अपना तरीका बदलते हैं तो उनका कोड टूट सकता है, भले ही वह तरीका पूरी तरह से ठीक हो।

मैं शायद इसे खत्म कर रहा हूं, लेकिन मुझे यह आम सहमति नहीं है कि एक इंटरफ़ेस वापस करना एक कार्यान्वयन वापस करने पर पसंद किया जाना है।

Comments

फिर वापस लौटें IEnumerable<T>और आपके पास समय सुरक्षा है। आप अभी भी सभी LINQ एक्सटेंशन विधियों का उपयोग कर सकते हैं जो आम तौर पर एक विशिष्ट प्रकार के लिए कास्टिंग करके प्रदर्शन का अनुकूलन करने की कोशिश करते हैं (जैसे ICollection<T>कि Countसंपत्ति का उपयोग करने के बजाय इसे एन्यूमरेट करने के लिए)।

— टिम श्मेल्टर

IList<T>एक "हैक" द्वारा लागू होता है। यदि आप इसे वापस करने की विधि को उजागर करना चाहते हैं, तो वास्तव में इसे लागू करने वाला एक प्रकार लौटाएं।

— कोडकैस्टर

बस ऐसे वादे न करें जिन्हें आप नहीं रख सकते। जब वह आपका "मैं एक सूची वापस करूंगा" अनुबंध पढ़ता है तो क्लाइंट प्रोग्रामर को निराश होने की बहुत संभावना है। ऐसा नहीं है बस ऐसा मत करो।

— हंस पसंत

से MSDN : IList ICollection इंटरफ़ेस का वंशज है और सभी गैर सामान्य सूची के आधार इंटरफेस है। IList कार्यान्वयन तीन श्रेणियों में आते हैं: केवल पढ़ने के लिए, निश्चित-आकार और परिवर्तनशील आकार में। केवल पढ़ने के लिए IList को संशोधित नहीं किया जा सकता है। एक निश्चित आकार का IList तत्वों को जोड़ने या हटाने की अनुमति नहीं देता है, लेकिन यह मौजूदा तत्वों के संशोधन की अनुमति देता है। एक चर-आकार IList तत्वों को जोड़ने, हटाने और संशोधित करने की अनुमति देता है।

— हामिद पूरजम

@AlexanderDerck: यदि आप चाहते हैं कि उपभोक्ता आपकी सूची में आइटम जोड़ सकता है, तो इसे IEnumerable<T>पहले स्थान पर न बनाएं । फिर वापस लौटना IList<T>या List<T>।

— टिम श्मेल्टर

Answer 1

हो सकता है कि यह सीधे आपके प्रश्न का उत्तर न दे रहा हो, लेकिन .NET 4.5+ में, मैं सार्वजनिक या संरक्षित APIs डिज़ाइन करते समय इन नियमों का पालन करना पसंद करता हूँ:

• वापस करो IEnumerable<T> , यदि केवल प्रतिपूर्ति उपलब्ध है;
• वापस करो IReadOnlyCollection<T>यदि गणना और आइटम संख्या दोनों उपलब्ध हैं ;
• वापसी करें IReadOnlyList<T>, यदि गणना, आइटम गणना और अनुक्रमित पहुंच उपलब्ध हैं;
• ICollection<T>यदि गणना, आइटम गणना और संशोधन उपलब्ध हैं, तो वापस लौटें ;
• वापसी करें IList<T>, यदि गणना, आइटम गिनती, अनुक्रमित पहुंच और संशोधन उपलब्ध हैं।

अंतिम दो विकल्प मानते हैं, कि विधि को IList<T>कार्यान्वयन के रूप में सरणी वापस नहीं करना चाहिए ।

Comments

वास्तव में उत्तर नहीं, लेकिन अंगूठे का अच्छा नियम और मेरे लिए बहुत उपयोगी :) मैं यह चुनने के लिए बहुत संघर्ष कर रहा हूं कि हाल ही में क्या लौटना है। चीयर्स!

— अलेक्जेंडर डर्क

यह वास्तव में सही सिद्धांत है +1। केवल पूर्णता के लिए मैं जोड़ूंगा IReadOnlyCollection<T>और ICollection<T>जो कि गैर अनुक्रमिक कंटेनरों के लिए उनका उपयोग है (उदाहरण के लिए बाद में ईएफ इकाई उप संग्रह नेविगेशन गुणों के लिए एक मानक है)

— इवान स्टोव

@IvanStoev क्या आप उन जोड़े के साथ कृपया जवाब संपादित कर सकते हैं? यह अच्छा होगा यदि मुझे अंत में एक सूची मिलती है कि किस इंटरफ़ेस का उपयोग करना है

— अलेक्जेंडर डर्क

यह ध्यान दिया जाना चाहिए कि IReadOnlyCollection<T>और IReadOnlyList<T>सी ++ के जैसा ही दोष constहै। दो संभावनाएँ हैं: या तो संग्रह अपरिवर्तनीय है, या यह संग्रह तक आपकी पहुंच का एकमात्र तरीका है जो आपको इसे मॉडरेट करने से मना करता है। और आप एक से दूसरे को नहीं बता सकते।

— ACH

@Panzercrisis: मैं दूसरा विकल्प चुनूंगा, निश्चित रूप से - IEnumerable<T>। API डेवलपर के रूप में आपको अनुमत उपयोग-मामलों के बारे में पूरी जानकारी है। यदि विधि परिणामों को केवल गणना करने का इरादा है, तो उजागर करने का कोई कारण नहीं है IList<T>। परिणाम के साथ कम करने की अनुमति दी, अधिक लचीला विधि कार्यान्वयन है। उदाहरण के लिए, एक्सपोज़िंग IEnumerable<T>आपको कार्यान्वयन को बदलने की अनुमति देता है yield return, IList<T>यह अनुमति नहीं देता है।

— डेनिस

Answer 2

नहीं, क्योंकि उपभोक्ता को पता होना चाहिए कि वास्तव में IList क्या है:

IList ICollection इंटरफ़ेस का वंशज है और सभी गैर-सामान्य सूचियों का आधार इंटरफ़ेस है। IList कार्यान्वयन तीन श्रेणियों में आते हैं: केवल पढ़ने के लिए, निश्चित-आकार और परिवर्तनशील आकार में। केवल पढ़ने के लिए IList को संशोधित नहीं किया जा सकता है। एक निश्चित आकार का IList तत्वों को जोड़ने या हटाने की अनुमति नहीं देता है, लेकिन यह मौजूदा तत्वों के संशोधन की अनुमति देता है। एक चर-आकार IList तत्वों को जोड़ने, हटाने और संशोधित करने की अनुमति देता है।

आप के लिए जाँच कर सकते हैं IList.IsFixedSizeऔर IList.IsReadOnlyऔर क्या आप इसके साथ चाहते हैं।

मुझे लगता IListहै कि यह एक वसा इंटरफेस का एक उदाहरण है और इसे कई छोटे इंटरफेस में विभाजित किया जाना चाहिए था और जब आप किसी सरणी को एक के रूप में लौटाते हैं तो यह लिस्कोव प्रतिस्थापन सिद्धांत का भी उल्लंघन करता है IList।

यदि आप इंटरफ़ेस वापस करने के बारे में निर्णय लेना चाहते हैं तो और पढ़ें

---

अपडेट करें

अधिक खुदाई और मैंने पाया कि IList<T>लागू नहीं होता है IListऔर IsReadOnlyबेस इंटरफेस के माध्यम से सुलभ है, ICollection<T>लेकिन इसके लिए कोई भी नहीं IsFixedSizeहै IList<T>। इस बारे में अधिक पढ़ें कि जेनेरिक IList <> गैर-जेनेरिक IList को विरासत में क्यों नहीं लेता है?

Comments

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

— अलेक्जेंडर डर्क

यह वास्तव में डेवलपर के लिए दयालु होता अगर वे एक अतिरिक्त इंटरफ़ेस प्रदान करते हैं जिसमें (गैर-निश्चित आकार / गैर-रीड-ओनली) List<T>शब्दार्थ है, लेकिन संभवतः ध्वनि तर्क है कि यह क्यों शामिल नहीं किया गया था ...। लेकिन, हां, मुझे लगता है कि विभिन्न विशेषताओं को कवर करने वाले कई इंटरफेस के बारे में आपका विचार एक बहुत अच्छा विकल्प होगा;

— स्पेंडर

IList<T>एक मोटी इंटरफ़ेस है, लेकिन यह सबसे अधिक है जो आप सरणी और सूची से प्राप्त कर सकते हैं । इसलिए यदि यह कई इंटरफेस में टूट जाता है, तो आप सूचियों और सरणियों के साथ कुछ तरीकों का उपयोग करने में सक्षम नहीं हो सकते हैं, लेकिन उनमें से केवल एक के साथ, भले ही आप जिन तरीकों का उपयोग करना चाहते हैं वे सभी समर्थित हैं (जैसे IList.Countया अनुक्रमणिका)। इसलिए मेरी राय में यह एक अच्छा निर्णय था। यदि यह NotSupportedExceptionउन बहुत कम मामलों में कारण बनता है जहां कोई Addएक सरणी पर उपयोग करना चाहता है , तो ठीक है, यह सौदा है।

— टिम श्मेल्टर

@dotctor क्या संयोग है, मैं कल Liskov प्रतिस्थापन सिद्धांत के बारे में पढ़ रहा था और मुझे वास्तव में सोच रहा था :) जवाब के लिए धन्यवाद

— अलेक्जेंडर डर्क

खैर डेनिस के नियमों के साथ संयुक्त यह उत्तर निश्चित रूप से इस दुविधा से निपटने के तरीके को समझने में सुधार कर सकता है। यह कहने की आवश्यकता नहीं है कि लिस्कोव प्रतिस्थापन सिद्धांत का उल्लंघन यहाँ और वहाँ .NET .NET में किया गया है और इसके बारे में चिंतित होने के लिए कुछ विशेष नहीं है।

— फब्जान

Answer 3

सभी "इंटरफ़ेस बनाम कार्यान्वयन" प्रश्न के साथ, आपको यह महसूस करना होगा कि सार्वजनिक सदस्य को उजागर करने का क्या मतलब है: यह इस वर्ग के सार्वजनिक एपीआई को परिभाषित करता है।

यदि आप List<T>एक सदस्य (क्षेत्र, संपत्ति, विधि, ...) के रूप में उजागर करते हैं, तो आप उस सदस्य के उपभोक्ता को बताते हैं: इस विधि का उपयोग करके प्राप्त किया गया प्रकार एक हैList<T> , या कुछ है कि के व्युत्पन्न।

अब यदि आप एक इंटरफ़ेस को उजागर करते हैं, तो आप एक ठोस प्रकार का उपयोग करके अपनी कक्षा के "कार्यान्वयन विवरण" को छिपाते हैं। बेशक आप इन्स्तांत नहीं कर सकते हैं IList<T>, लेकिन आप एक का उपयोग कर सकते Collection<T>, List<T>, derivations उसके या अपने खुद के प्रकार को लागू करनेIList<T> ।

वास्तविक सवाल यह है कि "क्यों करता है Arrayको लागू IList<T>" , या "क्यों है IList<T>इतने सारे सदस्यों इंटरफेस" ।

यह इस बात पर भी निर्भर करता है कि आप उस सदस्य के उपभोक्ताओं को क्या करना चाहते हैं। यदि आप वास्तव में अपने सदस्य के माध्यम से एक आंतरिक सदस्य लौटाते हैं Expose..., तो आप new List<T>(internalMember)वैसे भी वापस लौटना चाहेंगे , अन्यथा उपभोक्ता कोशिश कर सकते हैं और उन्हें डाल सकते हैंIList<T> अपने आंतरिक सदस्य को संशोधित कर सकते हैं।

यदि आप उपभोक्ताओं से परिणामों की पुनरावृति की अपेक्षा करते हैं, तो इसके बजाय IEnumerable<T>या उजागर करें IReadOnlyCollection<T>।

Comments

"वास्तविक प्रश्न यह है कि" ऐरे इलिस्ट <टी> को क्यों लागू करता है, या "इलिस्ट <टी> के पास इतने सारे सदस्य क्यों हैं", ", यह वास्तव में कुछ ऐसा है जिसके साथ मैं संघर्ष कर रहा था।

— अलेक्जेंडर डर्क

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

— ली

@ लियो वूप्स, आप सही कह रहे हैं, मेरी गलत टिप्पणी को हटाते हुए

— फब्जान

@AlexanderDerck यह कुछ मैंने पहले पूछा है stackoverflow.com/q/5968708/706456

— oleksii

@oleksii यह वास्तव में समान है, लेकिन मैं इसे डुप्लिकेट नहीं कहूंगा

— अलेक्जेंडर डर्क

Answer 4

कंबल उद्धरणों से सावधान रहें जो संदर्भ से बाहर हैं।

एक इंटरफ़ेस वापस करना एक ठोस कार्यान्वयन वापस करने से बेहतर है

यह उद्धरण केवल तभी समझ में आता है जब इसका उपयोग SOLID सिद्धांतों के संदर्भ में किया जाता है । 5 सिद्धांत हैं, लेकिन इस चर्चा के प्रयोजनों के लिए हम केवल अंतिम 3 के बारे में बात करेंगे।

निर्भरता उलटा सिद्धांत

एक को "सार पर निर्भर होना चाहिए। कॉन्फ्रेन्स पर निर्भर न रहें। ”

मेरी राय में, यह सिद्धांत समझना सबसे कठिन है। लेकिन यदि आप उद्धरण को ध्यान से देखते हैं तो यह आपके मूल उद्धरण जैसा दिखता है।

इंटरफेस (अमूर्तता) पर निर्भर। ठोस क्रियान्वयन (सम्‍मिलन) पर निर्भर न रहें।

यह अभी भी थोड़ा भ्रमित है लेकिन अगर हम दूसरे सिद्धांतों को एक साथ लागू करना शुरू करते हैं तो यह बहुत अधिक समझ में आता है।

लिस्कोव प्रतिस्थापन सिद्धांत

"एक कार्यक्रम में वस्तुओं को उस कार्यक्रम की शुद्धता में बदलाव किए बिना उनके उपप्रकारों के उदाहरणों के साथ बदली जानी चाहिए।"

जैसा कि आपने बताया, एक वापसी Arrayस्पष्ट रूप से एक अलग व्यवहार है, List<T>भले ही वे दोनों लागू हों IList<T>। यह निश्चित रूप से एलएसपी का उल्लंघन है।

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

इंटरफ़ेस अलगाव सिद्धांत

"कई ग्राहक-विशिष्ट इंटरफेस एक सामान्य प्रयोजन इंटरफ़ेस से बेहतर हैं।"

यदि आप एक इंटरफ़ेस लौटा रहे हैं, तो आपको अपने कार्यान्वयन का समर्थन करने वाले सबसे विशिष्ट ग्राहक इंटरफ़ेस को वापस करना चाहिए। दूसरे शब्दों में, यदि आप ग्राहक से इस Addपद्धति को कॉल करने की अपेक्षा नहीं कर रहे हैं तो आपको उस पर विधि के साथ एक इंटरफेस नहीं लौटाना चाहिए Add।

दुर्भाग्य से, .NET फ्रेमवर्क (विशेषकर शुरुआती संस्करण) में इंटरफेस हमेशा आदर्श ग्राहक विशिष्ट इंटरफेस नहीं होते हैं। हालांकि @Dennis ने अपने जवाब में बताया, .NET 4.5+ में बहुत अधिक विकल्प हैं।

Comments

लिस्कोव के सिद्धांत पर पढ़ना मुझे पहली बार उलझन में डाल गया थाIList<T>

— अलेक्जेंडर डर्क

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

— craftworkgames

Answer 5

एक संग्रह के ठोस कार्यान्वयन को वापस करने से बेहतर है कि एक इंटरफेस लौटना बेहतर नहीं है। आपके पास एक ठोस प्रकार के बजाय एक इंटरफ़ेस का उपयोग करने का हमेशा एक अच्छा कारण होना चाहिए। आपके उदाहरण में ऐसा करना व्यर्थ लगता है।

एक इंटरफ़ेस का उपयोग करने के लिए वैध कारण हो सकते हैं:

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

2. आप अपने वर्ग पदानुक्रम से स्वतंत्र कुछ सामान्य कार्यक्षमता को एक प्रकार से सुरक्षित तरीके से उजागर करना चाहते हैं। विभिन्न आधार प्रकारों की वस्तुएं जो समान तरीकों की पेशकश करती हैं वे आपके इंटरफ़ेस को लागू करेंगे।

एक तर्क दे सकता है कि 1 और 2 मूल रूप से एक ही कारण हैं। वे दो अलग-अलग परिदृश्य हैं जो अंततः एक ही आवश्यकता को जन्म देते हैं।

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

Comments

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

— अलेक्जेंडर डर्क

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

— कोडकास्टर

मैं सहमत हूं (वास्तव में), मुझे एक तीसरा कारण जोड़ना चाहिए था: "कॉल करने वाले को संदेश स्पष्ट करने के लिए उसके सार को किसी लौटे ऑब्जेक्ट की कार्यक्षमता को सीमित करें"। मैं भी पूरा संग्रह के लिए उपयोग की गई पूर्ण विकसित वस्तु के बजाय जब भी संभव हो IReadOnlyXxx इंटरफेस लौटाता हूं।

— मार्टिन माट