नामकरण के मुद्दे: क्या "कुछ" का नाम बदलकर "नामकरण" होना चाहिए? [बन्द है]

Question

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

चलो निम्नलिखित मान लेते हैं:

• इंटरफ़ेस उपयोग मुख्य रूप से निर्भरता इंजेक्शन के माध्यम से परीक्षणनीयता प्राप्त करने के लिए है
• कई मामलों में, यह एकल कार्यान्वयनकर्ता के साथ एकल इंटरफ़ेस होने की ओर जाता है

इसलिए, उदाहरण के लिए, इन दोनों का नाम क्या होना चाहिए? Parserऔर ConcreteParser? Parserऔर ParserImplementation?

public interface IParser {
    string Parse(string content);
    string Parse(FileInfo path);
}

public class Parser : IParser {
     // Implementations
}

या मुझे इस तरह के एकल-कार्यान्वयन के मामलों में इस सुझाव को अनदेखा करना चाहिए?

Comments

यह किसी भी धर्म से कम नहीं है। आप कारणों की तलाश करेंगे, न कि किसी एक्स का कहना है कि वाई

— माइक डनलवेई

@MikeDunlavey और इस सवाल का कारण है!

— विंको वर्सालोविच

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

— ट्रिपहाउंड

@ ट्राइपहाउंड मेजॉरिटी नियम हमेशा सबसे अच्छा विकल्प नहीं है। यदि कारण हैं तो कुछ चीजें दूसरों की तुलना में बेहतर हैं, एक अकेला व्यक्ति बाकी टीम को उन कारणों के आधार पर मामला बनाने के लिए मना सकता है। बस आँख बंद करके बहुमत के बिना चीजों का मूल्यांकन किए बिना ठहराव की ओर जाता है। मैं उन उत्तरों से देखता हूं कि इस ठोस मामले के लिए Is को हटाने का कोई अच्छा कारण नहीं है, लेकिन यह पहली जगह में पूछे जाने को अमान्य नहीं करता है।

— विंको वर्सालोविच 12

"अंकल बॉब की" पुस्तक JAVA पर केंद्रित है, न कि C #। अधिकांश प्रतिमान C # के साथ समान होते हैं, लेकिन कुछ नामकरण परंपराएं भिन्न होती हैं (जावा में लोअरमेनेलकैसे फ़ंक्शन नाम भी देखें)। जब आप C # में लिखते हैं, तो C # नामकरण सम्मेलनों का उपयोग करें। लेकिन वैसे भी, नामकरण पर उनके अध्याय के प्रमुख बिंदु का पालन करें: पठनीय नाम जो आइटम का अर्थ संवाद करते हैं!

— बर्नहार्ड हिलर

Answer 1

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

Comments

टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।

— Maple_shaft

आप "सामान्य शब्दों में, इसे टाला जाना चाहिए" के लिए कोई आधार नहीं है। जावा में, मुझे बचा जाना चाहिए। सी # में इसे गले लगाया जाना चाहिए। अन्य भाषाएं अपने स्वयं के सम्मेलनों का पालन करती हैं।

— बेसिक

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

— कैंडिड_ओरेंज

Answer 2

इंटरफ़ेस महत्वपूर्ण तार्किक अवधारणा है, इसलिए, इंटरफ़ेस को जेनेरिक नाम रखना चाहिए। तो, मैं बल्कि होता

interface Something
class DefaultSomething : Something
class MockSomething : Something

से

interface ISomething
class Something : ISomething
class MockSomething : ISomething

उत्तरार्द्ध में कई संकेत हैं:

1. कुछ केवल ISomething का एक कार्यान्वयन है, फिर भी यह जेनेरिक नाम के साथ एक है, जैसे कि यह किसी तरह विशेष था।
2. MockSomething कुछ से प्राप्त होता है, अभी तक ISomething लागू करता है। हो सकता है कि इसे मॉकिसोमेस्टिंग नाम दिया जाए, लेकिन मैंने कभी जंगली में नहीं देखा।
3. Refactoring कठिन है। यदि कुछ अब एक वर्ग है, और आपको केवल बाद में पता चलता है कि आपको एक इंटरफ़ेस शुरू करना है, तो उस इंटरफ़ेस का नाम समान होना चाहिए, क्योंकि यह क्लाइंट के लिए पारदर्शी होना चाहिए, चाहे वह एक ठोस वर्ग हो, एक सार वर्ग या एक इंटरफ़ेस हो । ISomething कि टूट जाता है।

Comments

आप C # प्रदान करने वाले सुस्थापित मानक का पालन क्यों नहीं करेंगे? यह लाभ प्रदान करता है जो आपके द्वारा अनुसरण करने वाले प्रत्येक C # प्रोग्रामर को भ्रमित करने और परेशान करने की लागत से अधिक है?

— रॉबर्ट हार्वे

@wallenborn यह ठीक है, लेकिन वास्तविक रूप से आपके पास अक्सर केवल एक इंटरफ़ेस का एक वैध कार्यान्वयन होता है, क्योंकि यूनिट परीक्षणों में मॉकबिलिटी के लिए इंटरफेस का उपयोग करना आम है। मैं डाल करने के लिए नहीं करना चाहते हैं Defaultया Realया Implमेरी कक्षा नाम के इतने में

— बेन Aaronson

मैं आपसे सहमत हूं, लेकिन अगर आप इस सड़क की यात्रा करते हैं तो आपको C # के लिए बनाए गए हर लिंटर से लड़ना होगा।

— रबरडुक

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

— सुपरकैट

@ArtB कारणों की जोड़ी। एक, वहाँ कोई भाषा नहीं है, जहां सम्मेलन वर्ग की तरह एक अच्छा लघु मार्कर है CFoo : Foo। तो वह विकल्प वास्तव में उपलब्ध नहीं है। दो, आपको एक अजीब असंगति मिलती है क्योंकि कुछ वर्गों में मार्कर होगा और अन्य नहीं होगा, इस पर निर्भर करता है कि क्या एक ही इंटरफ़ेस के अन्य कार्यान्वयन हो सकते हैं। CFoo : Fooलेकिन SqlStore : Store। यह एक समस्या है Implजो मेरे पास है , जो अनिवार्य रूप से सिर्फ एक बदसूरत मार्कर है। हो सकता है कि अगर हमेशा एक C(या जो भी हो) के सम्मेलन के साथ एक भाषा थी , तो इससे बेहतर हो सकता हैI

— बेन एरोनसन

Answer 3

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

class Foo : BarB, IBarA
{
    // Better...
}

... इस के लिए बेहतर है ...

class Foo : BarB, BarA
{
    // Dafuq?
}

IMO

Comments

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

— कोनराड रुडोल्फ

@KonradRudolph आपका मतलब है extends।

— ऑरेंजडॉग

@Andy अतिरिक्त मूल्य यह है कि हम हंगेरियन नोटेशन क्रॉफ्ट से बच सकते हैं, फिर भी इस उत्तर में स्पष्ट की गई सभी स्पष्टता को संरक्षित कर सकते हैं।

— कोनराड रुडोल्फ

वास्तव में कोई भ्रम नहीं होना चाहिए; यदि आपको एक वर्ग विरासत में मिला है, तो उसे लागू इंटरफेस की सूची से पहले सूची में होना चाहिए। मुझे पूरा यकीन है कि यह कंपाइलर द्वारा लागू किया गया है।

— एंडी

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

— रॉबी

Answer 4

नहीं नहीं नहीं।

नामकरण परंपराएं आपके अंकल बॉब फैंडिक्स का कार्य नहीं हैं। वे भाषा का एक फ़ंक्शन नहीं हैं, c # या अन्यथा।

वे आपके कोड आधार का एक कार्य हैं। अपनी दुकान की बहुत कम सीमा तक। दूसरे शब्दों में कोड बेस में पहला मानक सेट करता है।

इसके बाद ही आप निर्णय लेंगे। उसके बाद बस सुसंगत हो। यदि कोई असंगत होने लगता है तो अपनी nerf बंदूक को हटा दें और जब तक वे पश्चाताप नहीं करते, तब तक वे दस्तावेज़ अद्यतन करें।

एक नया कोड बेस पढ़ते समय अगर मुझे Iभाषा की परवाह किए बिना एक उपसर्ग मैं ठीक-ठाक दिखाई देता है । अगर मुझे हर एक इंटरफ़ेस दिखाई दे रहा है तो मैं ठीक हूँ। अगर मैं कभी-कभी एक, किसी का भुगतान करने जा रहा हूं।

यदि आप अपने कोड बेस के लिए इस मिसाल को स्थापित करने के दुर्लभ संदर्भ में खुद को पाते हैं तो मैं आपसे इस पर विचार करने का आग्रह करता हूं:

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

यदि आप Iउस नाम से डरते हैं , तो ग्राहक परवाह नहीं करता है। अगर वहाँ नहीं है I, तो ग्राहक परवाह नहीं करता है। जो बात कर रहा है वह ठोस हो सकता है। यह नहीं हो सकता है। चूंकि यह उस newपर कॉल नहीं करता है, इस तरह से कोई फर्क नहीं पड़ता है। ग्राहक के रूप में, मुझे नहीं पता। मैं जानना नहीं चाहता।

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

हो सकता है कि यह आपके लिए एक गैर मुद्दा हो। शायद नहीं। यदि ऐसा है, तो देखभाल करने का यह एक अच्छा कारण है। लेकिन डेस्क टॉयज के प्यार के लिए हमें यह दावा नहीं करना चाहिए कि हमें आंख मूंद कर ऐसा करना चाहिए क्योंकि यह किसी तरह से किया गया है। या तो कोई अच्छा कारण है या परवाह नहीं है।

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

Comments

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

— जैक्सबी

यदि आप C # का उपयोग कर रहे हैं, तो आप उन लोगों को देखने वाले हैं I। यदि आपका कोड उनका उपयोग करता है, तो आप उन्हें हर जगह देखेंगे। यदि आपका कोड उनका उपयोग नहीं कर रहा है, तो आप उन्हें फ्रेमवर्क कोड से देखेंगे, जो आपके इच्छित मिश्रण के लिए अग्रणी है।

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

Answer 5

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

इस धारणा के साथ चलने वाली धारणाएँ दिशानिर्देश - जावा में, हर सार्वजनिक प्रकार को गैर-अंतिम माना जाना चाहिए, जो लिस्कोव के प्रतिस्थापन सिद्धांत [1] के अनुसार है। यदि आपके पास केवल एक कार्यान्वयन है, तो आप कक्षा का नाम देंगे Parser; यदि आपको लगता है कि आपको कई कार्यान्वयन की आवश्यकता है, तो आप कक्षा को एक ही नाम के साथ एक इंटरफ़ेस में बदल देंगे, और कुछ कार्यान्वयन के लिए ठोस कार्यान्वयन का नाम बदल देंगे।

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

कार्यक्षमता के लिए गैर- I- उपसर्ग नाम छोड़ने में भी एक अच्छा प्रयोज्य सुविधा है जो इंटरफ़ेस को एक सार वर्ग बनाने के लिए सहारा के बिना संबंधित है (जो कि सी # में कई-विरासत के वर्ग की कमी के कारण चोट लगी होगी)। यह LINQ द्वारा लोकप्रिय किया गया था, जो IEnumerable<T>इंटरफ़ेस के रूप में उपयोग करता है, और Enumerableउस इंटरफ़ेस पर लागू होने वाले तरीकों के भंडार के रूप में। यह जावा में अनावश्यक है, जहां इंटरफेस में विधि कार्यान्वयन भी हो सकता है।

अंततः, IC # दुनिया में उपसर्ग का व्यापक रूप से उपयोग किया जाता है, और एक्सटेंशन के द्वारा, .NET दुनिया (क्योंकि अब तक अधिकांश .NET कोड C # में लिखे गए हैं, यह अधिकांश सार्वजनिक इंटरफेस के लिए C # दिशा-निर्देशों का पालन करने के लिए समझ में आता है)। इसका मतलब है कि आप लगभग निश्चित रूप से पुस्तकालयों और कोड के साथ काम कर रहे होंगे जो इस संकेतन का अनुसरण करते हैं, और यह अनावश्यक भ्रम को रोकने के लिए परंपरा को अपनाने के लिए समझ में आता है - यह उपसर्ग को छोड़ने की तरह नहीं है जो आपके कोड को किसी भी बेहतर बना देगा :)

मुझे लगता है कि अंकल बॉब का तर्क कुछ इस तरह था:

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

यदि आप इसे अपने नमूना IParserइंटरफ़ेस पर लागू करते हैं , तो आप स्पष्ट रूप से देख सकते हैं कि अमूर्तता पूरी तरह से "अर्थहीन" क्षेत्र में है। या तो वहाँ एक पार्सर (जैसे की एक ठोस कार्यान्वयन के बारे में कुछ विशिष्ट है JsonParser, XmlParser...), या तुम सिर्फ एक वर्ग का उपयोग करना चाहिए। "डिफ़ॉल्ट कार्यान्वयन" जैसी कोई चीज नहीं है (हालांकि कुछ वातावरणों में, यह वास्तव में समझ में आता है - विशेष रूप से, COM), या तो एक विशिष्ट कार्यान्वयन है, या आप "चूक" के लिए एक सार वर्ग या विस्तार के तरीके चाहते हैं। हालाँकि, C # में, जब तक कि आपका कोडबेस पहले से I-प्रिफ़िक्स को छोड़ नहीं देता है, तब तक रखें। बस हर बार एक मानसिक नोट बनाएं जैसे कि आपको कोड दिखाई देता है class Something: ISomething- इसका मतलब है कि कोई व्यक्ति YAGNI का अनुसरण करने और उचित सार का निर्माण करने में बहुत अच्छा नहीं है।

[१] - तकनीकी रूप से, यह विशेष रूप से लिस्कोव के कागज में उल्लिखित नहीं है, लेकिन यह मूल ओओपी पेपर की नींव में से एक है और लिस्कोव के मेरे पढ़ने में, उसने इसे चुनौती नहीं दी। कम सख्त व्याख्या में (अधिकांश ओओपी भाषाओं द्वारा लिया गया), इसका मतलब है कि किसी भी सार्वजनिक प्रकार का उपयोग करने वाला कोड जो प्रतिस्थापन के लिए अभिप्रेत है (यानी गैर-अंतिम / सील) उस प्रकार के किसी भी अनुरूप कार्यान्वयन के साथ काम करना चाहिए।

Comments

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

— कोनराड रुडोल्फ

@KonradRudolph मैंने इस बारे में एक फुटनोट जोड़ा; प्रतिक्रिया के लिए धन्यवाद :)

— लुआं

Answer 6

इसलिए, उदाहरण के लिए, इन दोनों का नाम क्या होना चाहिए? पार्सर और कंक्रीटपेयर? Parser और ParserIm कार्यान्वयन?

एक आदर्श दुनिया में, आपको अपना नाम शॉर्ट-हैंड ("I ...") के साथ उपसर्ग नहीं करना चाहिए, लेकिन बस नाम को एक अवधारणा व्यक्त करने दें।

मैं कहीं पढ़ता हूं (और इसे स्रोत नहीं बना सकता) यह राय है कि इस ISomething सम्मेलन आपको एक "आईडी कॉलर" अवधारणा को परिभाषित करने की ओर ले जाता है जब आपको "डॉलर" वर्ग की आवश्यकता होती है, लेकिन सही समाधान एक अवधारणा होगी जिसे बस "मुद्रा" कहा जाता है।

दूसरे शब्दों में, कन्वेंशन चीजों को नाम देने में कठिनाई को आसान बनाता है और आसान को आसानी से गलत करता है ।

---

वास्तविक दुनिया में, आपके कोड के क्लाइंट (जो कि "आप भविष्य से हो सकते हैं") को बाद में इसे पढ़ने में सक्षम होना चाहिए और जितनी जल्दी हो सके इससे परिचित होना चाहिए (या कम प्रयास के साथ) ग्राहकों को दें आपके कोड की वे क्या पाने की उम्मीद करते हैं)।

ISomething सम्मेलन, cruft / बुरे नामों का परिचय देता है। यह कहा गया है, जब तक कि कोड लिखने में उपयोग किए जाने वाले सम्मेलनों और प्रथाओं को वास्तविक नहीं माना जाता है, तब तक, cruft वास्तविक cruft *) नहीं है; यदि कन्वेंशन "ISomething का उपयोग करें" कहता है, तो इसका उपयोग करना सबसे अच्छा है, अन्य देवों के साथ अनुरूप (और बेहतर काम करने के लिए)।

---

*) मैं इस becasuse "cruft" कहकर दूर हो सकता है वैसे भी एक सटीक अवधारणा नहीं है :)

Answer 7

जैसा कि अन्य उत्तर उल्लेख करते हैं, आपके इंटरफ़ेस नामों को प्रीफ़िक्स करना I। .NET फ्रेमवर्क के लिए कोडिंग दिशानिर्देशों का हिस्सा है। क्योंकि ठोस कक्षाओं को अक्सर C # और VB.NET में जेनेरिक इंटरफेस की तुलना में अधिक इंटरैक्ट किया जाता है, वे नामकरण योजनाओं में प्रथम श्रेणी के होते हैं और इस प्रकार इसका सरलतम नाम होना चाहिए - इसलिए, IParserइंटरफ़ेस के Parserलिए और डिफ़ॉल्ट कार्यान्वयन के लिए।

लेकिन जावा और इसी तरह की भाषाओं के मामले में, जहां कंक्रीट कक्षाओं के बजाय इंटरफेस पसंद किए जाते हैं, अंकल बॉब सही है कि Iहटा दिया जाना चाहिए और इंटरफेस में Parserआपके पार्सर इंटरफ़ेस के लिए सबसे सरल नाम होना चाहिए - उदाहरण के लिए। लेकिन भूमिका-आधारित नाम के बजाय ParserDefault, वर्ग में एक ऐसा नाम होना चाहिए जो बताता है कि पार्सर कैसे लागू किया जाता है :

public interface Parser{
}

public class RegexParser implements Parser {
    // parses using regular expressions
}

public class RecursiveParser implements Parser {
    // parses using a recursive call structure
}

public class MockParser implements Parser {
    // BSes the parsing methods so you can get your tests working
}

यह कैसे उदाहरण के लिए, है Set<T>, HashSet<T>और TreeSet<T>नाम हैं।

Comments

Interfaces C # में भी पसंद किए जाते हैं। जिसने भी आपको बताया कि उसे डॉटनेट में ठोस प्रकारों का उपयोग करना पसंद था?

— रबरडुक

@ रुबरडक यह उन कुछ मान्यताओं में छिपा है जिन्हें भाषा आप पर थोपती है। उदाहरण के लिए, यह तथ्य कि सदस्य sealedडिफ़ॉल्ट रूप से हैं, और आपको उन्हें स्पष्ट रूप से बनाना चाहिए virtual। आभासी होना C # में विशेष मामला है। बेशक, लेखन कोड के लिए अनुशंसित दृष्टिकोण वर्षों में बदल गया, अतीत के कई अवशेषों को संगतता के लिए बने रहने की आवश्यकता है :) मुख्य बिंदु यह है कि यदि आपको C # में एक इंटरफ़ेस मिलता है (जो कि इसके साथ शुरू होता है I), तो आप जानते हैं कि यह पूरी तरह से है सार प्रकार; यदि आपको एक गैर-इंटरफ़ेस मिलता है, तो विशिष्ट धारणा यह है कि आप चाहते हैं कि प्रकार, एलएसपी को शापित किया जाए।

— लुआं

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

— रबरडाक

@ रबरडक हह, मैंने कभी नहीं कहा कि मुझे यह पसंद नहीं है। मैं इसे बहुत पसंद करता हूं, क्योंकि ज्यादातर लोग अप्रत्यक्ष रूप से नहीं समझते हैं । प्रोग्रामर्स के बीच भी। डिफ़ॉल्ट रूप से सील मेरी राय में बेहतर है। और जब मैंने C # से शुरुआत की, तो हर कोई एक शौकिया था। .NET टीम सहित :) "वास्तविक OOP" में, सब कुछ आभासी माना जाता है - प्रत्येक प्रकार को एक व्युत्पन्न प्रकार से बदली जानी चाहिए, जो किसी भी व्यवहार को ओवरराइड करने में सक्षम होना चाहिए । लेकिन "वास्तविक ओओपी" विशेषज्ञों के लिए डिज़ाइन किया गया था, न कि ऐसे लोग जिन्होंने प्रकाश बल्बों को बदलने से लेकर प्रोग्रामिंग तक की, क्योंकि यह अधिक पैसे के लिए कम काम है :)

— Luaan

नहीं ... नहीं। यह बिल्कुल नहीं है कि "वास्तविक ओओपी" कैसे काम करता है। जावा में, आपको उन तरीकों को सील करने का समय लेना चाहिए जिन्हें ओवरराइड नहीं किया जाना चाहिए, इसे वाइल्ड वेस्ट की तरह नहीं छोड़ना चाहिए जहां कोई भी सब कुछ सवारी कर सकता है। एलएसपी का मतलब यह नहीं है कि आप अपनी इच्छानुसार कुछ भी ओवरराइड कर सकते हैं। एलएसपी का मतलब है कि आप सुरक्षित रूप से एक वर्ग को दूसरे के साथ बदल सकते हैं। Smh

— रबरडक

Answer 8

आप सही हैं कि यह I = इंटरफ़ेस कन्वेंशन (नए) नियम तोड़ता है

पुराने दिनों में आप हर चीज को इसके प्रकार के साथ जोड़ देंगे उपसर्ग boolFlag आदि।

यदि आप उपसर्ग के बिना चीजों को नाम देना चाहते हैं, लेकिन 'कंकरीपर्सर' से भी बचें, तो आप नाम स्थान का उपयोग कर सकते हैं

namespace myapp.Interfaces
{
    public interface Parser {...
}


namespace myapp.Parsers
{
    public class Parser : myapp.Interfaces.Parser {...
}

Comments

नया? पुराना? रुको, मैंने सोचा कि प्रोग्रामिंग प्रचार की तुलना में तर्कसंगतता के बारे में अधिक थी। या पुराने दिनों में यह था?

कोई भी इसके बारे में सम्मेलनों और ब्लॉगिंग के बारे में नहीं है कि वे 'रीडबैलिटी में सुधार' कैसे करते हैं

— इवान

मेरा मानना ​​है कि आप हंगेरियन नोटेशन के बारे में सोच रहे हैं, जिसमें आपने वास्तव में प्रकारों के साथ उपसर्ग नाम किए थे। लेकिन वहाँ कोई समय है जिसमें आप की तरह कुछ लिखने होता था intCounterया boolFlag। वे गलत "प्रकार" हैं। इसके बजाय, आप लिखेंगे pszName(एक एनयूएल-टर्मिनेटेड स्ट्रिंग के लिए सूचक जिसमें एक नाम होता है), cchName(स्ट्रिंग "नाम" में वर्णों की गणना), xControl(एक्स कंट्रोल का समन्वय), fVisible(झंडा कुछ दिखाई दे रहा है), pFile(सूचक को इंगित करने के लिए) एक फ़ाइल), hWindow(एक खिड़की के लिए संभाल), और इतने पर।

— कोड़ी ग्रे

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

— कोड़ी ग्रे

@CodyGray जोएल स्पोल्स्की ने एक अच्छा लेख लिखा, जिसमें हंगर कोड संकेतन के बारे में गलत कोड देखो गलत है और यह (गलत) समझा गया है। उनकी एक समान राय है: उपसर्ग एक उच्च स्तर का प्रकार होना चाहिए, न कि कच्चे डेटा भंडारण प्रकार। वह "दयालु" शब्द का उपयोग करता है, यह समझाते हुए, "मैं इस तरह के उद्देश्य से वहाँ पर शब्द का उपयोग कर रहा हूँ , क्योंकि सिमोनी ने गलती से अपने कागज में शब्द प्रकार का उपयोग किया था , और प्रोग्रामर की पीढ़ियों ने गलत समझा कि उसका क्या मतलब है।"

— जोशुआ टेलर