.NET में इंटरफेस के लिए "I" उपसर्ग नामकरण सम्मेलन के पीछे तर्क क्या है?

Question

मुझे पता है कि "मैं" सम्मेलन COM के बाद से आस-पास रहा है, लेकिन मुझे कभी समझ नहीं आया कि .NET के पहले हर दूसरे नामकरण सम्मेलन की तरह इस पर पुनर्विचार क्यों नहीं किया गया।

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

मैंने यह भी सोचा कि ऐसा हो सकता है कि आप एक ही नाम के साथ इंटरफेस का एक बुनियादी कार्यान्वयन कर सकते हैं, उदाहरण के लिए Messageविरासत में मिला है IMessage, लेकिन अधिकांश .NET पुस्तकालयों के अंत में "आधार" शब्द जोड़ने के लिए गए हैं (उदाहरण के लिए System.Collections.ReadOnlyCollectionBase) - और यह अधिक अर्थपूर्ण समझ में आता है।

COM इंटरॉप एक और संभावित कारण लगता है - लेकिन ऐसा नहीं है कि रैपर कक्षाएं जो उत्पन्न करती हैं, वह पूरी तरह से मुहावरेदार .NET हैं, इसलिए मुझे संदेह है कि यह एक सौंदर्यवादी विचार था।

मेरी एक नई परियोजना में मैंने पूरी तरह से सम्मेलन को क्षमा कर दिया है, और यह ठीक लगता है। क्या मुझे कुछ याद आ रहा है?

Comments

आप उन्हें पूरा करने के लिए इंटरफेस, बड़े अंतर को प्राप्त नहीं करते हैं।

— डैनियल लिटिल

यह भी पसंद सूची और ArrayList के विपरीत IList और सूची की तरह लगता है। उन्होंने शायद यह इसलिए किया क्योंकि IList एक ListBase नहीं है, लेकिन वास्तव में एक ListInterface (टाइप इंटरफ़ेस की सूची नहीं) है, अगर आपको मेरा मतलब है।

— डैनियल लिटिल

@Lavinski In .NET IListएक अनुक्रमित, सन्निहित संग्रह, यादृच्छिक अभिगम के लिए एक सामान्य शब्द है, जबकि Listएक अनुक्रमित, सन्निहित, यादृच्छिक अभिगम, बढ़ता संग्रह है। मुझे लगता है कि एफ # यह सही aliasing में था Listकरने के लिए ResizeArray; यह निश्चित रूप से एक बहुत अधिक वर्णनात्मक नाम है। IListतब हो सकता था List, ताकि ऐसा न लगे कि यह भी एक कारण होगा।

— री मियासाका

IBaseBall और IBaseBallBase, BaseBallBase और BaseBallBaseBase (मूर्खतापूर्ण उदाहरण, मुझे पता है: D) की तुलना में मेरे लिए अधिक समझ में आता है

— e-MEE

@ ई-एमईई उतना ही मूर्खतापूर्ण IIRC होगा, जो IRC चैट प्रोटोकॉल के लिए एक इंटरफ़ेस हो सकता है, या "अगर मुझे सही याद है" के लिए संक्षिप्त नाम।

— री मियासका

Answer 1

मुझे लगता है कि यह एकमात्र ऐसा मामला हो सकता है जब उपसर्ग उपयोगी हो।

कक्षाएं और इंटरफेस वास्तव में अलग-अलग शब्दार्थ हैं, और क्योंकि दोनों प्रकार हैं, मिश्रण करना आसान है।
जब मैं एक वर्ग घोषणा देखते हैं, मैं तुरन्त क्या यह बता सकते हैं से निकला है और क्या यह लागू करता है :

public sealed class ActivityCollection : List<Activity>, 
    IList<Activity>, ICollection<Activity>, IEnumerable<Activity>, 
    IList, ICollection, IEnumerable

यह समझना कठिन होगा कि परिभाषा कैसी दिखती है

public sealed class ActivityCollection : ListClass<Activity>, 
    List<Activity>, Collection<Activity>, Enumerable<Activity>, 
    List, Collection, Enumerable

और कैसे पुकारोगे ListClass? स्पष्ट रूप से यह सिर्फ ListBaseइसलिए नहीं है क्योंकि यह अपने आप में प्रयोग करने योग्य है।
इसलिए, हमें या तो एक समस्या को हल करना होगा जिसका हमने अभी आविष्कार किया है, या एक उपसर्ग को अनुकूलित करें जो कक्षाओं को इंटरफेस से अलग करता है, जो कि .NET फ्रेमवर्क डिजाइनरों ने किया है।

इसके अलावा, व्यक्तिगत रूप से मुझे यह उपयोगी लगता है जब मैं विधि हस्ताक्षर से बता सकता हूं कि यह इंटरफेस के साथ काम करता है।

public void PrintLines (IEnumerable<string> source)

यह मेरे सिर के लिए एक संकेत की तरह है: हे, मैं इसे लागू कर सकता हूं! मैं अनुबंध से मेल खाने वाली विधि को फ़ीड कर सकता हूं।

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

वैसे, न केवल इंटरफेस में .NET प्रकार सिस्टम में उपसर्ग होते हैं। सामान्य प्रकार के मापदंडों के बारे में मत भूलना:

public delegate TResult Func<in T, out TResult>(
    T arg
)

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

Comments

आप यह आसानी से समझ सकते हैं कि यह जानकर कि "पहली कक्षा विरासत है, दूसरी कक्षा और आगे इंटरफेस हैं"।

— सईद नेमाटी

यह एक प्रशंसनीय कारण लगता है। जावा बस सूची स्पष्ट करने के लिए कीवर्ड का उपयोग करके थोड़ा और अच्छी तरह से इसे हल है लगता है: class Dog extends Mammal implements MailmanChaser। @ यदि आपके पास एक वर्ग हो सकता है जो किसी भी चीज़ से विरासत में नहीं मिलता है, तो सूची में पहला प्रकार वास्तव में एक आधार वर्ग के बजाय एक इंटरफ़ेस है।

— री मियासका

बोल्डफेस भाग के लिए +1, हालांकि मैं एक अन्य स्थान के बारे में सोच सकता हूं जहां एक उपसर्ग-आधारित सम्मेलन मददगार होगा: एक ऐसे क्षेत्र के बीच अंतर करने के लिए जो int[](या अन्य प्रकार की परस्पर वस्तु) के विशेष स्वामित्व को अतिक्रमण करता है जिसे वह बदल सकता है लेकिन नहीं शेयर, और एक है कि एक का स्वामित्व साझा encapsulates int[], भले ही इसके प्रकार उत्परिवर्तन की अनुमति देगा, किसी को भी म्यूट करने की अनुमति नहीं है।

— सुपरकैट

Answer 2

मुझे नहीं लगता कि आपकी कुछ भी याद आ रही है, यह सिर्फ एक ऐतिहासिक आदत है।

मैं आपके साथ भी सहमत हूँ और बिना किसी हानिकारक प्रभाव के छोटे से मध्यम प्रोजेक्ट पर 'आई' को गिरा दिया है।

Comments

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

— री मियासाका

Answer 3

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

हालाँकि, मैं व्यक्तिगत रूप से इस बात से पूरी तरह से सहमत हूँ कि हम इंटरफ़ेस के लिए एनिमल बेस , और क्लास के लिए एनिमल का उपयोग कर सकते हैं ।

दूसरी ओर, कभी-कभी दो चीजें इतनी अधिक परस्पर विरोधी होती हैं, कि एक टीम पहले से तैयार निर्णयों के बावजूद, आगे के संघर्षों को रोकने के लिए एक सम्मेलन प्रदान करने का निर्णय लेती है। उदाहरण के लिए, ASP.NET MVC में, आंशिक दृश्य और लेआउट (मास्टर पृष्ठ) दोनों एक सामान्य दृश्य की तरह हैं , जबकि वे अलग-अलग कार्यक्षमता रखते हैं। इस प्रकार Microsoft नामकरण में अंडरस्कोर का उपयोग न करने पर जोर देने के बावजूद, अंडरस्कोर के साथ लेआउट और आंशिक दृश्यों को रेखांकित करने का सुझाव देता है ।

Comments

AnimalInterfaceइसके बजाय क्या गलत है AnimalBase? यह एक आधार वर्ग नहीं है, यह एक इंटरफ़ेस है।

— स्कॉट व्हिटलॉक

लेकिन IAnimal के साथ AnimalInterface के बजाय क्या गलत है? सुनिश्चित करें कि हम शुरू करने के लिए सभी तरह के दौर में चले गए हैं - जो सिर्फ यह दिखाने के लिए जाता है कि कुछ 'आयु' नोटेशन उपयोगी थे। एक बेहतर प्रणाली को खोजने के लिए एक सोची समझी कोशिश के बजाय उन सभी को बाहर फेंकना (I और T को छोड़कर) अधिक मनमुटाव था।

— gbjbaanb

@ScottWhitlock: मेरे लिए, IAnimalकी तुलना में बहुत अधिक पठनीय है AnimalInterface। वर्बोज़ नाम उन मामलों को छोड़कर बेहतर है जब एक साधारण लघु सम्मेलन का उपयोग अक्सर होने वाली किसी चीज़ के लिए किया जा सकता है। और इंटरफेस एक ऐसा मामला है।

— मातरिनस