अमूर्त वर्गों के लिए नामकरण सम्मेलनों

Question

मुझे स्पष्ट रूप से याद है कि, एक समय में, Microsoft द्वारा धक्का दिया गया दिशानिर्देश "एब्स" प्रत्यय को एक अमूर्त वर्ग में जोड़ने के लिए था ताकि इस तथ्य को कम किया जा सके। इसलिए, हम जैसे श्रेणियां होती हैं System.Web.Hosting.VirtualFileBase, System.Configuration.ConfigurationValidatorBase, System.Windows.Forms.ButtonBase, और, ज़ाहिर है, System.Collections.CollectionBase।

लेकिन मैंने देखा है कि, देर से, फ्रेमवर्क में बहुत सारे अमूर्त वर्ग इस सम्मेलन का पालन नहीं करते हैं। उदाहरण के लिए, निम्नलिखित वर्ग सभी सार हैं लेकिन इस सम्मेलन का पालन नहीं करते हैं:

• System.DirectoryServices.ActiveDirectory.DirectoryServer

• System.Configuration.ConfigurationElement

• System.Drawing.Brush

• System.Windows.Forms.CommonDialog

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

तो, क्या मैं इसे खो रहा हूं? क्या यह दिशानिर्देश कभी मौजूद था? क्या यह सिर्फ एक शब्द के बिना छोड़ दिया गया है? क्या मैं पिछले दो वर्षों से बिना किसी के लिए अपने आप से लंबे वर्ग के नाम बना रहा हूं?

कोई मुझे यहाँ एक हड्डी फेंक दे।

अपडेट मैं पागल नहीं हूं। गाइडलाइन मौजूद थी। 2005 में Krzysztof Cwalina ने इसके बारे में पकड़ बनाई।

Comments

यदि आप उस टुकड़े को पढ़ते हैं, तो Krzysztof केवल "सिफारिशों का एक सेट" प्राप्त करने के बारे में शिकायत करता है - जरूरी नहीं कि वे सिफारिशें Microsoft-आधिकारिक थीं। मुझे याद है कि एमएस के दिशानिर्देशों को पढ़ना और उन्हें इसके खिलाफ सलाह देना याद है।

— जॉन रुडी

मैंने इसे पढ़ा, हालाँकि यह पहली बार है जब मुझे याद आया कि मैंने उस विशेष लेख को देखा है। यह वास्तव में राहत की बात है। मुझे वास्तव में सिफारिश पसंद नहीं है। यह मुझे यहाँ से बाहर बढ़ने के बहुत से बचा लेगा। :)

— माइक हॉफ़र

Answer 1

में फ्रेमवर्क डिजाइन दिशानिर्देश पी 174 कहता है:

यदि सार्वजनिक APIs में उपयोग के लिए वर्ग का नाम "आधार" प्रत्यय के साथ नामकरण वर्गों से बचें ।

इसके अलावा: http://blogs.msdn.com/kcwalina/archive/2005/12/16/BaseSuffix.aspx

Answer 2

इसके अलावा, अगर सार वर्ग में कुछ स्थिर सदस्य हैं जिनका उपयोग किया जाएगा, तो 'आधार' बदसूरत हो सकता है।

Answer 3

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

जैसा कि आप देखते हैं, आप शायद एक विधि की घोषणा नहीं करेंगे जो एक बटनबेस को पैरामीटर के रूप में स्वीकार करता है। यह उपवर्गों के लिए न्यूनतम कार्यक्षमता प्रदान करने के लिए डिज़ाइन किया गया है। हालाँकि, आप ConfigurationElementएक ऐसी इकाई के रूप में व्यवहार कर सकते हैं जिसके विभिन्न रूप हैं लेकिन यह अपने आप में पूर्ण नहीं है (और इसलिए यह सार है)

Answer 4

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

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

मुद्दा यह है कि ऐसे मामले हैं जहां आधार प्रत्यय का उपयोग करने का कोई बेहतर विकल्प नहीं है।

Comments

मैं सहमत हूँ। मैं एक फीड सिस्टम में काम कर रहा हूं जो विभिन्न स्रोतों से सामग्री को पार्स करता है। हम सार्वजनिक API का उपयोग IFeedParser नाम के एक इंटरफ़ेस में करते हैं , और आंतरिक रूप से हम एक आधार सार वर्ग का उपयोग करते हैं जिसमें BaseFeedParser

— रुई जारिम्बा

Answer 5

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

एक विकल्प के रूप में: मैं वस्तु को "एक निर्दिष्ट जाति या परिवार से संबंधित" या ( विक्षनरी: -आदि ) के रूप में "प्रत्यय" के रूप में उपयोग कर सकता हूं ।

उदाहरण: DataProviderऔर ReflectiveDataProviderदोनों हैंDataProviderKind

जीवविज्ञान से प्रेरित होकर जहां "कैनिस ल्यूपस" परिवार "कैनोइडिया" से संबंधित है, जो बहुत ही मोटे तौर पर "डॉग-ईश" में अनुवाद करता है।

Answer 6

Microsoft कहता है:

https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-classes-structs-and-interfaces

"" CONSIDER बेस क्लास के नाम के साथ व्युत्पन्न वर्गों के नाम को समाप्त करता है। यह बहुत ही पठनीय है और रिश्ते को स्पष्ट रूप से समझाता है। कोड में इसके कुछ उदाहरण हैं: ArgumentOutOfRangeException, जो एक तरह का अपवाद है, और SerializableAttribute, जो एक प्रकार है। इस प्रकार की विशेषता। हालांकि, इस दिशानिर्देश को लागू करने में उचित निर्णय का उपयोग करना महत्वपूर्ण है, उदाहरण के लिए, बटन वर्ग एक प्रकार का नियंत्रण कार्यक्रम है, हालांकि नियंत्रण इसके नाम में प्रकट नहीं होता है। "

आम तौर पर, यह स्पष्ट रूप से नाम में "आधार" का उपयोग करता है।