इंटरफ़ेस नामकरण: उपसर्ग 'कैन-' बनाम प्रत्यय '-एबल'

Question

इंटरफेस जैसे उदाहरण के लिए प्रत्यय के रूप में '-able' का उपयोग करना आम है

सीरियल करने योग्य मुद्रण योग्य असंख्य पीने योग्य घूर्णन योग्य

मैं सोच रहा था कि 'कैन-' बेहतर हो सकता है क्योंकि यह अधिक वर्णनात्मक हो सकता है। हां, यह अधिक चिंताजनक है और यह इंटरफ़ेस के नाम में शोर जोड़ता है। विशेष रूप से, निष्क्रिय क्रियाओं का उपयोग किया जा सकता है।

जैसे 1 शूट करने योग्य का मतलब है कि ऑब्जेक्ट शूट करने में सक्षम है (एक बंदूक इसे लागू कर सकती है), या इसका मतलब यह है कि इसे शूट किया जा सकता है (एक लक्ष्य बोर्ड इसे लागू कर सकता है)। 'Can-' उपसर्ग के साथ, पूर्व "CanShoot" होगा और बाद में "CanBeShotAt" या "CanShootAt" होगा।

उदाहरण 2 एक दस्तावेज 'कैनब्रींटेड' और एक प्रिंटर 'कैनप्रिंट'

या, क्या हमें '-एबल' से चिपके रहना चाहिए और दस्तावेज को संदर्भ प्रदान करना चाहिए?

कोई राय।

Comments

यार, "-able" का उपयोग करें। अवधि।

— ट्यूलेंस कोरडोवा

दोनों के लिए उपयोग करेंclass Cannibal implements Can, Able {}

— थॉमस एडिंग जूल

Answer 1

शायद आप सक्षम हैं?

.Net से कुछ उदाहरण:

NetworkStream.Readable
NetworkStream.Writable
Stream.CanRead
Stream.CanWrite
Type.IsSerializable

एक समान मानक प्रतीत नहीं होता है। जो अच्छा पढ़ता है, उसके साथ जाओ।

if (document.IsPrintable && printer.CanPrint) { printer.Print(document) }

संपादित करें: जैसा कि इंगित किया गया था, सवाल गुण के बारे में नहीं था।

उस स्थिति में, मुझे कोई भी इंटरफेस नहीं मिल सकता है जिसका नाम Can- है। इंटरफेस हमेशा उपयोग करने योग्य होते हैं। मैं इस शब्दावली से सहमत हूँ। एक विधि एक पैरामीटर ISerializable objectया एक के रूप में अनुरोध कर सकती है IPrintable document। एक के लिए पूछ रहा ICanBeSerialized objectहै या एक ICanBePrinted documentबहुत पढ़ने के लिए अजीब है।

दूसरी तरफ, प्रिंटर, मैं बस इंटरफ़ेस कॉल करने का सुझाव दूंगा IPrinter। आपका तरीका पूछ रहा होगा IPrinter device।

नीचे दिए गए विधि हस्ताक्षर को ज़ोर से पढ़ें। (व्यक्तिगत रूप से, मैं "मैं" उपसर्ग को मौन मानता हूं।) क्या यह अच्छी तरह से पढ़ा जाता है? क्या यह सही लगता है?

void PrintDocument(IPrinter device, IPrintable document)
{
    device.Print(document)
}

Comments

डॉक्यूमेंट .sPrintable Document.CanBePrinted से बेहतर है। जहाँ तक मैं बता सकता हूँ कि वे निष्क्रिय आवाज से बचने के लिए इस्तेमाल-योग्य थे।

— थानोस पपथनसीउ

"प्रिंट किया जा सकता है" ऐसा लगता है कि "प्रिंट करने योग्य" की तुलना में अधिक उचित अंग्रेजी है।

— डैनी व्रॉड

"निष्क्रिय आवाज़ का उपयोग तब किया जाता है जब ध्यान क्रिया पर होता है। यह महत्वपूर्ण या ज्ञात नहीं है, हालांकि, कौन या कौन क्रिया कर रहा है।" मैं केवल अनुमान लगा सकता हूं कि वे चाहते थे कि वस्तु पर ध्यान केंद्रित किया जाए और कार्रवाई नहीं। इसलिए यदि "Type.IsSerializable" एक अपवाद फेंकता है, तो यह Type का दोष है। विधियों का नहीं, लेकिन यदि कोई "Type.CanBeSerialized" अपवाद को फेंकता है, तो आप विधि को दोष देंगे और प्रकार को नहीं। बेशक अंतर मामूली है, लेकिन यह वहाँ है।

— थानोस पापनाथनियो

मैं देखता हूं कि यह स्वीकृत उत्तर है, लेकिन यह ओपी के प्रश्न का उत्तर नहीं देता है। प्रदान किए गए उदाहरण संपत्ति के नाम हैं। ओपी इंटरफ़ेस नामों, जैसे , और ISerializable, के लिए एक नामकरण सम्मेलन के लिए पूछ रहा है । IDataErrorInfoINotifyPropertyChanged

— केविन मैककॉर्मिक

@KevinMcCormick, अच्छी बात है! ऊपर संपादन।

— हैंड-ई-फूड

Answer 2

व्याकरणिक रूप से बोलना, "canFoobar" एक विधेय है, जबकि "Foobarable" एक विशेषण या एक संज्ञा है (आमतौर पर एक एपीआई के संदर्भ में एक संज्ञा)।

सूक्ष्म अंतर पर भी ध्यान दें: -इसका तात्पर्य उस संज्ञा के लिए एक निष्क्रिय भूमिका से है, जिस पर इसे लागू किया जाता है, अर्थात यदि कोई चीज़ फ़ॉबरेबल है, तो इसे किसी अन्य चीज़ से फ़ॉबर्ड किया जा सकता है; can- से तात्पर्य एक सक्रिय भूमिका से है, जो कि अगर कुछ कर सकता है, तो वह कुछ और कर सकता है। या, एक अलग कोण से: यदि A फ़ॉबर बी कर सकता है, तो A.canFoobar()और B is Foobarable।

OOP अभिव्यंजकता के संदर्भ में, मैं विधियों या गुणों के साथ संबद्ध करना चाहता हूं, जबकि संज्ञाएं वर्ग या इंटरफेस हैं। इसलिए:

instance.canFoobar();

class Something implements Foobarable { ... }

Answer 3

व्यक्तिगत रूप से मैं -able संस्करण के साथ रहना होगा। यहाँ मेरा कारण है: अधिकांश (सभी?) चित्रमय संपादकों ने आपके द्वारा लिखे गए के आधार पर पहचानकर्ताओं को सुझाव दिया है। हालाँकि उनमें से कुछ 'स्मार्ट' हैं जो पहचानकर्ताओं के भीतर भी खोज करने के लिए पर्याप्त हैं और कुछ अभी भी पहचानकर्ताओं की खोज शुरू करते हैं।

टाइपिंग को गति देने के लिए आप सुझाए गए पहचानकर्ताओं की सूची को कम से कम कीस्ट्रोक्स से कम करना चाहते हैं। अधिक पहचानकर्ताओं की एक ही शुरुआत होती है, उदाहरण के लिए 'ICan-' और अधिक अक्षर आपको टाइप करने होंगे।

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

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

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

Comments

+1। मेरा तर्क समान होगा, आईडीई में खोज / खोज / छांटना आसान बनाने के लिए पहले नियंत्रण क्रिया डालें।

— पाप

न केवल इंटैलिजेंस उस तरह से काम करता है, बल्कि एक मानव स्कैनिंग पाठ भी करता है, उपसर्ग आपके कोड को कम पठनीय बनाते हैं

— jk।

Answer 4

स्पष्ट रूप से उपसर्ग और प्रत्यय विभिन्न प्रकार के कार्यों के लिए लगभग स्पष्ट विकल्प हैं या एक कार्रवाई के विभिन्न दिशाओं के बजाय ।

वर्तमान उपयोग और प्राथमिकताएँ कई कारणों से असंगत हो सकती हैं, हालाँकि।

ऑब्जेक्ट द्वारा कार्रवाई की जाती है :
CanShoot -> यह शूट करता है (पर) कुछ
CanFly -> यह
CanChange उड़ता है -> यह बदलता है

कार्रवाई किया जाता है पर वस्तु:
-> पठनीय आप यह पढ़ सकते हैं
लिखने योग्य -> आप (करने के लिए) लिख सकते हैं
मुद्रण योग्य -> आप यह मुद्रित कर सकते हैं

हालांकि यह एक नियम या आवश्यक रूप से तार्किक भी नहीं हो सकता है, यह कन्वेंशन को अपनाने और चर नामकरण में उपयोग की निरंतरता बनाए रखने में मदद करता है।

Answer 5

मुझे लगता है कि आप क्षमता और अनुमति के बीच अंतर करना चाह सकते हैं। जबकि Serializableऔर CanSerializeइसका मतलब है कि कुछ क्रमबद्ध होने में सक्षम है, वहाँ भी अनुमति के मुद्दे हैं (या शायद डिस्क स्थान की कमी) और आपको विचार करने की आवश्यकता हो सकती है MaySerialize। चीजों को छोड़ने के ~ableबीच अंतर करने की आवश्यकता को हटाता है canऔर may।

Comments

SerializableIfNotDiskFullAndIfNotPermissionMissing ... लोल :)

— मैक्स

Answer 6

जब उपवर्गों को लागू करने / लागू करने में मुझे लगता है कि अंगूठे का नियम यह है कि आपको "बी एक ए" (जहां बी ए लागू होता है) कहने में सक्षम होना चाहिए। यह कहना सही नहीं लगता:

A Documentएक हैCanBePrinted

लेकिन यह कहना सही है (या कम से कम बेहतर):

A Documentएक हैPrintable

Answer 7

मुझे लगता है कि व्याकरण-वार और कन्वेंशन-वार Xable दोनों ही इंटरफेस के नामों के लिए बेहतर हैं, जबकि IsX, CanX, DoX गुणों के नामों के लिए बेहतर हैं।

MSDN से:

"एक सकारात्मक वाक्यांश के साथ बुलियन गुणों को नाम दें (कैंटसेक के बजाय कैनसेक)। वैकल्पिक रूप से, आप बूलियन गुणों को इस, कैन, या हस के साथ भी उपसर्ग कर सकते हैं, लेकिन केवल जहां यह मूल्य जोड़ता है।" http://msdn.microsoft.com/en-us/library/ms229012.aspx

Comments

सहायक लिंक के लिए +1; मैं कभी भी यह पता नहीं लगा सकता कि चीजों को क्या नाम देना है

— CamelBlues

Answer 8

मेरी राय में "-योग्य" संस्करण बहुत अधिक पठनीय है, फिर आपका प्रस्तावित "कैनडोसमेल" जो बहुत अधिक ऊंट कूबड़ लगाता है।

Comments

और कैन- अधिक विधि नाम है

— शाफ़्ट फ्रीक

संपत्ति का नाम - MSDN देखें। एक विधि का नाम "क्रिया या क्रिया वाक्यांश" होना चाहिए। इसके अलावा, कई कूबड़ में क्या गलत है?

— डैनी व्रॉद

Answer 9

स्काला में, *Ableइंटरफेस के लिए उपयोग किया जाता है, लेकिन Can*टाइप क्लास पैटर्न के लिए उपयोग किया जाता है। अनिवार्य रूप से, कुछ विधियों को कॉल करने में सक्षम होने के लिए, एक निश्चित प्रकार का एक निहित मूल्य गुंजाइश में मौजूद होना चाहिए। इस प्रकार का नाम कभी-कभी उपसर्ग होता है Can।

Comments

Can * एक वर्ग का अच्छा नाम नहीं है। MSDN से उद्धरण: "संज्ञाओं, संज्ञा वाक्यांशों, या कभी-कभी विशेषण वाक्यांशों के साथ पास्कल आवरण का उपयोग करके नाम वर्ग, इंटरफ़ेस और मान प्रकार करें", लिंक: msdn.microsoft.com/en-us/library/ms909040.aspx अच्छा नाम वर्ग दस्तावेज़ होगा, स्वीकार्य नाम प्रिंट करने योग्य होगा।

— डैनी वरोड

स्काला भाषा में एक उदाहरण है CanBuildFrom। यह एक विशेषण वाक्यांश होगा। इस वर्ग का उपयोग-मामला अन्य वर्गों की तुलना में बहुत अलग है। इस वर्ग के उदाहरण लगभग कभी भी निर्मित नहीं होते हैं और न ही ग्राहक द्वारा हल किए जाते हैं - बल्कि, वे कुछ प्रकारों के लिए गुंजाइश में उपलब्ध हैं। यदि वे एक निश्चित प्रकार के लिए उपलब्ध हैं, तो उस प्रकार के तरीकों को शामिल किया जाता है जिन्हें इस टाइपकास्ट की आवश्यकता होती है। यह एक एक्स्टेंसिबिलिटी मैकेनिज्म को सबटाइपिंग की तुलना में अधिक लचीला बनाने के लिए मौजूद है। Scala-lang.org/node/114 देखें ।

— axel22

मुझे केवल यूनिट परीक्षणों के लिए इंटरफेस को लागू करने वाले मॉक कक्षाओं के लिए विशेषण वाक्यांशों का उपयोग करना याद है - क्योंकि उनकी कोई वास्तविक भूमिका नहीं थी।

— डैनी व्रोड