क्या इंटरफ़ेस के नाम "I" उपसर्ग से शुरू होने चाहिए?

Question

मैं रॉबर्ट मार्टिन द्वारा " क्लीन कोड " पढ़ रहा हूँ उम्मीद है कि, एक बेहतर प्रोग्रामर बनें। हालांकि इसका कोई भी अब तक वास्तव में आधार नहीं है, लेकिन इससे मुझे लगता है कि जिस तरह से मैं एप्लिकेशन डिजाइन करता हूं और कोड लिखता हूं।

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

मैं इंटरफेस को अनसुना छोड़ना पसंद करता हूं। पूर्ववर्ती I, आज ​​की विरासत वाले वार्डों में इतनी सामान्य, सबसे अच्छी और बहुत अधिक जानकारी में एक व्याकुलता है। मैं नहीं चाहता कि मेरे उपयोगकर्ता यह जान सकें कि मैं उन्हें एक इंटरफ़ेस सौंप रहा हूँ ।

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

इसलिए, मेरा सवाल यह है कि "हमें इस तथ्य को क्यों छिपाना चाहिए कि कोड का कुछ हिस्सा एक इंटरफ़ेस की अपेक्षा कर रहा है?"

संपादित करें

एक जवाब के जवाब में:

यदि आपका प्रकार एक इंटरफ़ेस है या एक वर्ग आपका व्यवसाय है, तो आपके कोड का उपयोग करने वाले किसी व्यक्ति का व्यवसाय नहीं। इसलिए आपको इस थ्रिड पार्टी कोड में अपने कोड का विवरण लीक नहीं करना चाहिए।

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

Comments

मैं आपकी बात से सहमत हूं। एक बिंदु है जब बहुत अधिक जानकारी छिपाना बहुत मददगार नहीं है। हालाँकि, यदि आप इस दिशानिर्देश का पालन करते हैं, तब भी आप आईडीई या एड-ऑन का उपयोग करके प्रकार बता पाएंगे।

— NoChance

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

— थिटॉन

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

— Aaronaught

पुन to know whether they will be implementing an interface or extending a class: हाँ, लेकिन आपके कोड के अधिकांश उपयोगकर्ता इसे कॉल करेंगे, इसे लागू नहीं करेंगे या इसका विस्तार नहीं करेंगे, और वे वास्तव में परवाह नहीं कर सकते कि यह कौन है।

— david.pfx

इसके लायक क्या है, मैं बड़े पैमाने पर "मैं" उपसर्ग पसंद करता हूं। मैं भी एक ही कारण के लिए अमूर्त वर्गों पर एक "सार" उपसर्ग का उपयोग करता हूं। यह वर्ग / इंटरफ़ेस के उपभोक्ताओं के लिए कोई फर्क नहीं पड़ता है, लेकिन उन लोगों के लिए एक बड़ा अंतर बना सकता है जिन्हें इसके उदाहरण प्रदान करने की आवश्यकता है, और यह अन्य डेवलपर्स के लिए बहुत सरल बनाता है जो आपके कोड को पढ़ रहे हैं। इसका मतलब है कि वे एक नज़र में देख सकते हैं कि वे किसके साथ काम कर रहे हैं, इसके बजाय अधिक जानकारी के लिए मामले के आधार पर एक मामले में आईडीई से परामर्श करें। मैंने बस कोणीय का उपयोग करना शुरू कर दिया है और मुझे यह वास्तव में कष्टप्रद लग रहा है कि वे इस सम्मेलन का पालन नहीं करते हैं!

— दान राजा

Answer 1

यदि आप इसके बारे में सोचना बंद कर देते हैं, तो आप देखेंगे कि एक इंटरफ़ेस वास्तव में शब्दार्थ वर्ग से बहुत अलग नहीं है:

• दोनों के तरीके और / या गुण (व्यवहार) हैं;
• न तो गैर-निजी क्षेत्र (डेटा) होना चाहिए;
• न तो सीधे तात्कालिक हो सकता है;
• एक से व्युत्पन्न का अर्थ है किसी भी अमूर्त विधियों को लागू करना, जब तक कि व्युत्पन्न प्रकार भी सार न हो।

वास्तव में, वर्गों और इंटरफेस के बीच सबसे महत्वपूर्ण अंतर हैं:

• इंटरफेस में निजी डेटा नहीं हो सकता है;
• इंटरफ़ेस सदस्यों तक पहुँच संशोधक नहीं हो सकते हैं (सभी सदस्य "सार्वजनिक" हैं);
• एक वर्ग कई इंटरफेस को लागू कर सकता है (जैसा कि आम तौर पर केवल एक आधार वर्ग से विरासत में प्राप्त करने में सक्षम होने के विपरीत)।

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

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

विशिष्ट, वैनिला, रन-ऑफ-द-मिल व्यापार तर्क कोड के लिए, हालांकि, अमूर्त वर्ग और इंटरफेस के बीच के अंतर को विज्ञापित करने की आवश्यकता नहीं है क्योंकि वे कभी भी खेल में नहीं आएंगे।

यह सब कहा जा रहा है, मैं अपने C # इंटरफेस को Iकिसी भी तरह से उपसर्ग करता हूं क्योंकि यह Microsoft द्वारा उपयोग और वकालत की गई .NET कन्वेंशन है। और जब मैं एक नए डेवलपर को कोडिंग सम्मेलनों की व्याख्या कर रहा हूं, तो यह माइक्रोसॉफ्ट के नियमों का उपयोग करने की तुलना में बहुत कम परेशानी है, यह समझाने की तुलना में कि हमारे अपने "विशेष" नियम क्यों हैं।

Comments

इस टूटने के लिए धन्यवाद। +1 "वर्गों और इंटरफेस के बीच सार्थक अंतर के लिए ..."

— चार्ल्स स्प्रेबेरी

+1 के लिए "यह सब कहा जा रहा है, मैं अपने C # इंटरफेस को पहले से वैसे भी उपसर्ग करता हूं क्योंकि वह Microsoft द्वारा उपयोग किए गए .NET कन्वेंशन और वकालत है"। यह C # में मेरे लिए पर्याप्त है। इस सामान्य मानक का पालन करने से यह अधिक संभावना है कि अन्य .NET प्रोग्रामर इंटरफ़ेस की पहचान करते हैं।

— रोबोट

जैसा कि कोई व्यक्ति जो जावा और सी # दोनों बयान लिखता है "यह सब कहा जा रहा है, मैं वैसे भी अपने सी # इंटरफेस के साथ उपसर्ग करता हूं क्योंकि यह माइक्रोसॉफ्ट द्वारा उपयोग किए गए .NET कन्वेंशन और वकालत है" समझा नहीं जा सकता - यह उन चीजों में से एक है जो मुझे यह याद रखने में मदद करता है कि मैं किस भाषा में काम कर रहा हूँ

— Aidos

.NET (लेकिन जावा में नहीं) में एक और अंतर यह है कि कई .NET लैंग्वेजेस इंटरफेस को स्टैटिक मेथड्स की अनुमति नहीं देती हैं, इसलिए Iकिसी इंटरफेस को हैक करने से क्लास के लिए इंटरफेस से जुड़े स्टैटिक मेथड को अच्छा नाम दिया जा सकता है (जैसे) Enumerable<T>.Emptyया Comparer<T>.Default)।

— सुपरकैट

मुझे एक चिंता है। C ++ में यदि आप एक हेडर खोलते हैं और देखते हैं कि class Fooपहले से ही विस्तारित है class Bar, तो यह तुरंत स्पष्ट नहीं है कि class Barक्या बढ़ाया या कार्यान्वित किया जा रहा है। तो अब आपको class Barयह तय करने के लिए हैडर में देखना होगा कि क्या class Fooविस्तार के लिए संशोधित करना ठीक है class Baz। इसके अलावा, मैं उपसर्ग एक स्पष्ट दृश्य सुराग देता है अगर "एकल आधार वर्ग" का उल्लंघन किया जा रहा है या नहीं - तो आप हर बार जब आप हेडर खोलते हैं तो आपको एक पवित्रता की जांच मिलती है।

— jsj

Answer 2

कई मायनों में, सम्मेलन की तुलना में स्थिरता अधिक महत्वपूर्ण है। जब तक आप अपनी नामकरण योजनाओं में सुसंगत हैं, तब तक उनके साथ काम करना मुश्किल नहीं होगा। यदि आप चाहें तो I के साथ उपसर्गों का अवरोधन करें, या बस नाम को छोड़ दें, यह तब तक मेरे लिए महत्वपूर्ण नहीं है जब तक आप एक शैली चुनते हैं और उसके साथ चिपके रहते हैं!

Comments

स्थिरता> सम्मेलन के लिए +1। C # में आप I के साथ उपसर्ग करेंगे और जावा में आप नहीं करेंगे। अलग-अलग कार्य अलग-अलग सम्मेलनों के लिए बुलाते हैं

— ब्रिंगरहेल

+1 करते समय मैं व्यक्तिगत रूप से पसंद नहीं करता कि मेरे इंटरफेस पर है, BCL और 3rd पार्टी लाइब्रेरी के साथ असंगत होने के कारण .Net प्रोजेक्ट्स एक विकल्प imho नहीं है।

— जे.के.

Answer 3

पुस्तक अच्छी सामग्री से भरी है, लेकिन मैं अभी भी इंटरफ़ेस नाम में "I" जोड़ूंगा।

कल्पना कीजिए कि आपके पास public interface ILogएक डिफ़ॉल्ट कार्यान्वयन है public class Log।

अब, यदि आप करने का निर्णय लेते हैं public interface Log, तो अचानक आपको public class LogDefaultउन पंक्तियों पर लॉग क्लास या कुछ को बदलना होगा । आप सात में एक अतिरिक्त चरित्र रखने से गए - निश्चित रूप से यह बेकार है।

सिद्धांत और व्यवहार के बीच अक्सर एक अच्छी रेखा होती है। सिद्धांत रूप में यह वास्तव में अच्छा विचार है, लेकिन व्यवहार में यह इतना अच्छा नहीं है।

Comments

यह .NET प्रलेखन

— लेविनिन्जा

"कल्पना करें कि आपके पास डिफ़ॉल्ट कार्यान्वयन सार्वजनिक वर्ग लॉग के साथ सार्वजनिक इंटरफ़ेस ILog है।" - फिर आपके डिफ़ॉल्ट कार्यान्वयन के लिए आपके पास एक खराब नाम है। क्या करता Logहै? कंसोल में लॉग इन करें? Syslog करने के लिए? कहीं नहीं? जिन्हें क्रमशः कहा जाना चाहिए ConsoleLog, SyslogLogऔर NullLog। Logएक ठोस वर्ग का अच्छा नाम नहीं है, क्योंकि यह कोई ठोस नाम नहीं है।

— सेबेस्टियन रेडल

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

— रिचर्ड

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

— सेरगुट

@RichardTingle लेकिन मुझे लगता है कि सामान्य उपयोग बस इतना है कि MyClassइसमें एक परिवर्तनशील बदलाव है, है ना? यही है, हम अक्सर ऐसे तरीकों का उपयोग करते हैं जो अनिवार्य रूप से सार्वजनिक तरीकों को वास्तव में एक फैशन में सार्वजनिक करते हैं जो परीक्षण के लिए अनुमति देता है। (नहीं कह रही है कि अच्छा है या बुरा है, लेकिन समझने अक्सर है कि इंटरफेस के लिए प्रेरणा बस वर्गों कि निर्भरता आसानी से mockable 1 से 1 की व्याख्या करता है बनाने के लिए MyClassकरने के लिए IMyClassमैपिंग।)

— Ruffin

Answer 4

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

हालाँकि, जब थर्ड पार्टी कोड (एक्सप्ले के लिए एप्लिकेशन का दूसरा मॉड्यूल) आपको डेटा में हेरफेर करता है, तो इस कोड को ध्यान नहीं देना चाहिए कि क्या आप एक इंटरफ़ेस या एक क्लास प्रस्तुत कर रहे हैं।

यह अमूर्तता का पूरा बिंदु है। आप इस तीसरे पक्ष के कोड को एक दिए गए प्रकार का एक ऑब्जेक्ट प्रस्तुत कर रहे हैं। इस दिए गए प्रकार में कुछ सदस्य फ़ंक्शन हैं जिन्हें आप कॉल कर सकते हैं। बस काफी है।

यदि आपका प्रकार एक इंटरफ़ेस है या एक वर्ग आपका व्यवसाय है, तो आपके कोड का उपयोग करने वाले किसी व्यक्ति का व्यवसाय नहीं। इसलिए आपको अपने कोड का विवरण इस तीसरे पक्ष के कोड में लीक नहीं करना चाहिए।

वैसे, इंटरफेस और कक्षाएं अंत में संदर्भ प्रकार हैं। और यही मायने रखता है। तो यह है कि आपके नामकरण सम्मेलन पर जोर देना चाहिए।

Comments

@ मट> हाँ, यह मेरी एक गलती थी, और मैंने इसे संपादित किया।

— डेडलिंक

Answer 5

अधिकांश उत्तरों से लगता है कि प्रोग्रामिंग भाषा या तो जावा या सी # है जहां इंटरफेस / अमूर्त कक्षाओं के लिए एक अवधारणा (या कीवर्ड) है। इन मामलों में, एक सभ्य आईडीई में, यह तुरंत दिखाई देता है कि किस प्रकार का वर्ग एक सौदा करता है और लिखना public interface IMyClassअनावश्यक दोहराव है। यह ऐसा है जैसे आप लिखेंगे public final FinalMyClass- हर कीवर्ड को कक्षाओं के नाम पर रखने की कल्पना करेंगे ।

हालाँकि, C ++ में मेरी राय में स्थिति थोड़ी भिन्न है क्योंकि किसी को हेडर फ़ाइल में गोता लगाना पड़ता है और यह देखना होता है कि क्या कक्षा के पास यह पता लगाने के लिए कोई आभासी विधियाँ हैं या नहीं। उस मामले में, मैं स्पष्ट रूप से लिखने के लिए एक तर्क देख सकता हूं class AbstractMyClass।

तो मेरा जवाब होगा: यह प्रोग्रामिंग भाषा पर निर्भर करता है।

अपडेट किया गया २०१६: सी ++ अनुभव के २ साल बाद मैं अब कक्षा नामों के साथ उपसर्ग करने के लिए इसे बुरा अभ्यास मानूंगा Abstract, हालांकि मैं कहूंगा कि शायद कोड आधार हैं जो इतने जटिल हैं कि यह समझ में आ सकता है।

Comments

क्या आप सुनिश्चित हैं कि यह प्रश्न का उत्तर है? आप अन्य उत्तरों को पढ़ना और अपने कुछ बिंदुओं को स्पष्ट करना पसंद कर सकते हैं।

— david.pfx 11:14

C ++ में निश्चित रूप से इंटरफेस है, भले ही इसके लिए कोई कीवर्ड न हो। आप उस वर्ग को क्या कहते हैं, जहाँ प्रत्येक सदस्य फ़ंक्शन शुद्ध आभासी है और कोई सदस्य चर नहीं हैं?

@ david.pfx: मुझे लगता है कि मैं इस प्रश्न का सटीक उत्तर देता हूं "क्या इंटरफ़ेस के नाम" I "उपसर्ग से शुरू होने चाहिए?": यह प्रोग्रामिंग भाषा पर निर्भर करता है। अगर आपको लगता है कि मेरा विस्तार पर्याप्त स्पष्ट नहीं है, तो मुझे इसमें सुधार करने में खुशी हो रही है - आपके लिए कौन से हिस्से स्पष्ट नहीं हैं?

— एला। .२

@ जॉनघन: निश्चित रूप से इसमें इंटरफेस है! लेकिन मेरी पूरी बात यह है कि यह कीवर्ड के बारे में है। C ++ में एक नहीं है, इसलिए यह IDE / उपयोगकर्ता को दिखाई नहीं देता है यदि वह इंटरफ़ेस से संबंधित है या नहीं। जावा में, हालांकि, यह तुरंत दिखाई देता है।

— Ela782

शीर्ष-रेटिंग उत्तर पढ़ें और अपनी तुलना करें। आप SO के लिए नए हैं, और यह सीखने का एक अवसर है कि किस प्रकार के उत्तर वोट आकर्षित करते हैं। जैसा कि यह खड़ा है, तुम्हारा नहीं होगा। अधिक काम, अधिक स्पष्टीकरण, अधिक मूल्य के साथ, यह बस हो सकता है। वहाँ पर लटका हुआ!

— david.pfx

Answer 6

उस भाषा के मुहावरों का पालन करें जिसका आप उपयोग कर रहे हैं।

प्रत्येक भाषा के अपने मुहावरे और कोडिंग दिशानिर्देश होते हैं। उदाहरण के लिए, C # में, I के साथ I में उपसर्गों का पूर्व-निर्धारण करना मुहावरेदार है, यह नहीं है।

Comments

+1 उस भाषा के मुहावरों का अनुसरण करें जिसका आप उपयोग कर रहे हैं। जाहिर है पुस्तक लेखक एक जावा डेवलपर है। .NET / C #: ILog जावा: लॉग लेकिन नुकसान: जब मुझे पसंद है एक लॉग वर्ग है जो ILog इंटरफ़ेस को लागू करता है .... MyLog, LogDefault, LogBase, ...? बदसूरत, है ना? अधिक बदसूरत है: LogImpl ....: D

— hfrmobile

Answer 7

मेरे (जावा) कोड में, मुझे इस कन्वेंशन में एपीआई है जिसे मैं कॉल करने वालों को उजागर करता हूं:

• कार्यक्षमता इंटरफेस के माध्यम से प्रदान की जाती है, और कक्षाओं द्वारा कभी नहीं ।
• गैर-कार्यात्मक भाग कक्षाएं हैं।

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

नामकरण सम्मेलनों के संदर्भ में, इंटरफेस अभिनेता संज्ञा (जैसे, FooBarWatcher) या विशेषण (जैसे, FooBarWatchable) के लिए मैप करते हैं और दोनों शुद्ध डेटा कक्षाएं और एन्यूमरेशन मैप को गैर-सक्रिय संज्ञा (जैसे, FooBarStatus); आईडीई विशेष नामकरण सम्मेलनों के बिना एपीआई उपभोक्ता का मार्गदर्शन कर सकता है। अपवाद हमेशा की तरह जावा सम्मेलनों (पालन FooBarException, FooBarError, FooBarFaultनिश्चित रूप से)।

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

Comments

मैंने कभी भी Iउपसर्गों को इंटरफेस पर नहीं रखा । का पाठ्यक्रम यह एक अंतरफलक है! यह एक एपीआई (या SPI) में है!

— डोनाल्ड फैलो