क्या मुझे अपने अमूर्त वर्गों में "सार" उपसर्ग जोड़ना चाहिए? [बन्द है]

Question

मान लीजिए कि मेरा नाम एक अमूर्त वर्ग है Task।

क्या कोई मानक या सम्मेलन है जो यह सुझाएगा कि मुझे इसके AbstractTaskबजाय नाम देना चाहिए ?

Comments

: यहाँ सूचीबद्ध नामकरण परंपराओं oracle.com/technetwork/java/codeconventions-135099.html , कोई सुझाव है इस लिंक हालांकि: stackoverflow.com/questions/1006332/... कहते हैं आप कर सकता है और यह एक भयानक बात है, तो तुमने किया था नहीं होगा।

— FrustratedWithFormsDesigner

C # में मानक सम्मेलन '* आधार' के साथ प्रत्यय है।

— डेन

Answer 1

बलोच के प्रभावी जावा (आइटम 18) के अनुसार सार उपसर्ग एक विशेष मामले में उपयोग किया जाने वाला एक सम्मेलन है।

आप प्रत्येक nontrivial इंटरफ़ेस के साथ जाने के लिए एक अमूर्त कंकाल कार्यान्वयन वर्ग प्रदान करके इंटरफेस और अमूर्त वर्गों के गुणों को जोड़ सकते हैं। ... कन्वेंशन द्वारा, कंकाल कार्यान्वयन को AbstractInterface कहा जाता है, जहां इंटरफ़ेस उस इंटरफ़ेस का नाम है जिसे वे लागू करते हैं।

लेकिन बलोच यह भी बताते हैं कि स्केलेटलइंटरफेस नाम का अर्थ समझ में आया होगा, लेकिन यह निष्कर्ष निकलता है

अमूर्त सम्मेलन अब दृढ़ता से स्थापित है।

जैसा कि अन्य उत्तरों ने बताया है, सामान्य तौर पर सभी अमूर्त वर्गों के लिए इस नामकरण सम्मेलन को लागू करने का कोई कारण नहीं है।

Answer 2

कोई सम्मेलन नहीं है। यह सब कुछ है जो आपको डेवलपर की मदद करेगा, तेजी से और बेहतर कोड, और दूसरों को आपके कोड को समझने में मदद करेगा।

उन लोगों से पूछें जो कोड को देख रहे हैं और बनाए रखेंगे। बल्कि वे क्या देखेंगे? यह उन पर क्या आसान बना देगा? फिर इसका नाम इस आधार पर रखें कि वे क्या चाहते हैं।

एक अन्य नोट पर, जावा प्रोग्रामिंग लैंग्वेज के लिए कोड कन्वेंशन: 9. नामकरण कन्वेंशन कोई आवश्यकता नहीं बताता है:

वर्ग के नाम संज्ञाएं होनी चाहिए, मिश्रित मामले में प्रत्येक आंतरिक शब्द के पहले अक्षर के साथ पूंजीकृत। अपने वर्ग के नाम को सरल और वर्णनात्मक रखने का प्रयास करें। संपूर्ण शब्दों से बचें, समरूपता और संक्षिप्तताओं से बचें (जब तक कि संक्षिप्त रूप लंबे रूप से अधिक व्यापक रूप से उपयोग नहीं किया जाता है, जैसे URL या HTML)।

Answer 3

नहीं, अगर यह अमूर्त है, तो Intellisense तुच्छ रूप से मुझे बताएगा, इसलिए आप यहाँ DRY का उल्लंघन कर रहे हैं।

Comments

-1 abstractएक वर्ग के नाम को जोड़ना DRY का उल्लंघन नहीं करता है, और हर कोई अंतरंगता का उपयोग नहीं करता है। उदाहरण के लिए, यदि आप एक वेब पेज पर कोड पढ़ रहे हैं, या यदि यह एक पैच का हिस्सा है जिसे आप एक सादे टेक्स्ट एडिटर या बाहरी अंतर टूल में देख रहे हैं तो आप क्या करते हैं?

— ब्रायन ओकले

@ ब्रायन: बेशक यह DRY का उल्लंघन करता है। abstract class AbstractName? स्पष्ट रूप से दो बार "सार" है। और अगर आप Intellisense का उपयोग नहीं कर रहे हैं, तो यह आपकी समस्या है, बाकी सभी लोग कोड देखने के लिए समझदार टूल का उपयोग करते हैं।

— DeadMG

"Everbody"? मैं जानता हूं कि ज्यादातर लोग ग्रहण का उपयोग करते हैं, कुछ के साथ emacs और vi का उपयोग करते हैं। कुछ कहना "आपकी समस्या" टीमवर्क की परिभाषा नहीं है। मेरा खराब बनाया गया बिंदु था, आप केवल एक कंबल नियम निर्धारित नहीं कर सकते और कह सकते हैं कि यह कैसे किया जाता है। अलग-अलग टीमों की अलग-अलग आवश्यकताएं होती हैं, और हर किसी को अंतर्मुखता के साथ सहायता की आवश्यकता नहीं होती है। साथ ही, जैसा कि मैंने कहा, कई बार जब आप अपने प्राथमिक संपादक या आईडीई के अलावा किसी टूल में कोड देख रहे होते हैं।

— ब्रायन ओकले

+1 निश्चित रूप से DRY का उल्लंघन करता है। Intellisense पर भरोसा करना थोड़ा मजबूत है, लेकिन आधार वर्ग का उपयोग करने वाले किसी को भी कम से कम यह देखने के लिए देखना चाहिए कि वे SOLID के हिस्से के रूप में क्या कर रहे हैं।

— गैरी रोवे

@BryanOakley क्यों नहीं सार्वजनिक और अंतिम रूप में भी? एक वर्ग का नाम तब PublicAbstractPersonThatImplementsInterfaceHuman जैसा दिखेगा। हम्म, यकीन नहीं है कि अच्छा है। लेकिन मैं मानता हूं, एक सार्वभौमिक सम्मेलन के रूप में ऐसा कुछ नहीं है - जो कुछ भी टीम की सामूहिक उत्पादकता को बढ़ाता है उसका उपयोग करें।

— अपूर्व खुरसिया

Answer 4

यह कुछ हद तक प्राथमिकता का विषय है (लेकिन सीमावर्ती बुरे अभ्यास), लेकिन अधिकांश लोग कक्षा के नाम पर क्वालीफायर का हिस्सा देखना पसंद नहीं करते हैं।

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

Answer 5

.NET में, अमूर्त आधार वर्ग को निरूपित करने के लिए एक प्रत्यय के रूप में "आधार" का उपयोग अक्सर देखा जाता है। मैं अन्य उत्तरों के लिए टाल दूंगा कि क्या यह जावा में सामान्य अभ्यास है।

Comments

"बेस" और "इम्पल" प्रत्यय के लिए +1। वे एक संरचनात्मक बिंदु बनाते हैं (एक अमूर्त वर्ग कुछ के लिए आधार होगा)।

— vski

@vski: नहीं, मैं दृढ़ता से असहमत हूं: वे बट में एक बेकार दर्द हैं। सामान्य रूप से इंटरफ़ेस का वर्णन करने वाले एक सामान्य नाम के साथ आपके इंटरफ़ेस या बेस क्लैसेज़ का नाम देना ठीक है, और अधिक खोज नामों के साथ आपका ठोस कार्यान्वयन।

— जाइलम

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

— स्टारब्ले

@ हेलम कई जावा डिजाइन पैटर्न केवल एक अपेक्षित कार्यान्वयन के साथ इंटरफेस का उपयोग करते हैं। इन मामलों में Impl एक बहुत ही उपयोगी प्रत्यय है।

— फंकीब्रॉन

Impl के उपयोग के संबंध में, डिफ़ॉल्ट बनाम Impl देखें - Impl से दूर रहें! आधार को प्रत्यय के रूप में उपयोग करना (जैसे टास्कबेस) का अर्थ है कि भाषा निर्माण के बजाय एक आधार वर्ग एक पैटर्न है।

— गैरी रोवे

Answer 6

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

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

सामान्य तौर पर, नामकरण सम्मेलन के पक्ष में जो आपकी कक्षा के लक्ष्य के बारे में सबसे अधिक जानकारी देने में मदद करता है।

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

विचार करें:

IVehicle <-- IMotoredVehicle <-- AbstractCar <-- CarImpl

विरोध के रूप में:

Vehicle <-- MotoredVehicle <-- Car <-- DefaultCar
                                   <-- Ferrari
                                   <-- Trabi

मैं बहुत बाद तक पसंद करता हूं।

---

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

Answer 7

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

नियम का सामान्य अपवाद तब होता है जब नाम अस्पष्ट होता है। यदि, जो भी कारण से, एक ठोस उपवर्ग है Task(अन्य उदाहरणों में, यह अधिक समझदार हो सकता है, लेकिन जो भी हो), फिर सुनिश्चित करें, उपयोग करें AbstractTask।

Comments

... या एक इंटरफ़ेस जैसे कि Listऔर AbstractListवर्ग (जो इसे लागू करता है)।

Answer 8

protected abstract SomeClass { }

यह मुझे बताता है कि यह एक सार वर्ग है। उपसर्ग जोड़ना एक तनातनी और विरोधी पैटर्न है और ज्यादातर मामलों में उपयुक्त नहीं है, लिंक देखें जहां यह package localउदाहरण के लिए अपवाद होने की बात करता है ।

ज्यादातर मामलों में Abstractकक्षाएं सार्वजनिक सामना करने वाले एपीआई का हिस्सा नहीं होनी चाहिए, अगर यह वास्तव में एक अच्छा कारण होना चाहिए और एक अच्छा कारण के अलावा एक स्पष्ट रूप से अच्छा नाम प्रदान करना चाहिए AbstractSomeClass।

ज्यादातर मामलों में अगर आप अधिक वर्णनात्मक नाम के साथ नहीं आ सकते हैं तो आपको शायद कुछ नया करने की जरूरत है।

Answer 9

मेरे पांच सेंट, संभवतः आपके पास उस अमूर्त वर्ग के कार्यान्वयन होंगे और उन्हें 'SomeSpecificTask', 'TaskWithBubbles', 'StrangeTask' आदि नाम दिए जाएंगे, इसलिए आपके अमूर्त 'टास्क' और उनके बीच कोई नाम टकराव नहीं होगा।

इसके अतिरिक्त, 'अमूर्त' शब्द भाषा के सिंटैक्स के बारे में है, न कि व्यावसायिक डोमेन संस्थाओं के लिए, इसलिए मैं इसे नाम के एक भाग के रूप में उपयोग नहीं करना चाहूंगा।

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

Comments

public abstract class AbstractList<E> extends AbstractCollection<E> implements List<E>- कोई वर्ग Listके नाम के रूप में उपयोग नहीं कर सकता AbstractListक्योंकि वह इंटरफ़ेस का नाम है। यह एक अच्छी तरह से स्थापित अभ्यास और आधिकारिक जावा कोड का हिस्सा है जो उपयोग में है जहां कुछ ऐसा है जो इंटरफ़ेस को लागू करता है या एक सार वर्ग का विस्तार नहीं कर सकता है (जो कि इंटरफ़ेस को भी लागू करता है) (कुछ)।

Answer 10

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

यदि आप अपने दम पर काम करते हैं, तो यह पूरी तरह से आपके ऊपर है, इस साइट पर मैं या कोई और नहीं।

Answer 11

मैं एक जावा डेवलपर (INAJD?) नहीं हूं और ऐसी चीजों के लिए मानक नामकरण नहीं जानता, लेकिन मुझे लगता Taskहै कि यह पर्याप्त लगता है कि यह अकेले ही खड़ा हो सकता है।

Comments

रे: बेस प्रत्यय: stackoverflow.com/a/429494/1782

— जुआन

Answer 12

यदि आप एक सार AbstractSyntaxTreeवर्ग लिखना चाहते हैं तो क्या होगा ? या शायद सिर्फ एक सार SyntaxTree?

यह पारंपरिक नहीं है और यह लोगों को आसानी से भ्रमित कर सकता है।

Answer 13

मैंने यह कर दिया। मैंने अपने सार वर्ग के लिए उपसर्ग के रूप में 'Abstract' को AbstractOperation नाम से जोड़ा। मैंने ऐसा करने का कारण एक और पैकेज था जिसमें ऑपरेशन नामक एक गैर-सार वर्ग था, और इससे मेरी टीम और प्रोग्रामरों को मदद मिली, जिन्होंने दोनों के बीच किसी भी भ्रम से बचने के लिए बाद में कार्यभार संभाला।