क्या मुझे अपने सभी अमूर्त वर्गों का नाम देना चाहिए सारफू

Question

क्या यह सुनिश्चित करने के लिए अच्छा अभ्यास है कि सभी अमूर्त वर्गों के नाम "सार" के साथ उपसर्ग हैं?

Answer 1

आप ऐसा कर सकते हैं क्योंकि यह एक कार्यान्वयन विस्तार है।

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

Answer 2

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

यदि आप पहले से ही इंटरफ़ेस Foo नहीं रखते हैं तो आप उन्हें FooBase भी कह सकते हैं, या सिर्फ Foo।

Answer 3

यदि आप मानते हैं कि यह .NET ढांचे में कैसे है, नहीं। उदाहरण के लिए सार स्ट्रीम वर्ग ले लो। कक्षा के नाम में कुछ भी इंगित करता है कि यह वास्तव में सार है।

Answer 4

मुझे इस फैशन में कक्षाओं का नाम देने में उपयोगी लगता है। यह एक संदेश भेजता है कि वे उप-वर्गीकृत होने का इरादा रखते हैं; तत्काल नहीं; उप-वर्गों के लिए सामान्य कोड शामिल है, आदि

हालांकि यह हमेशा आवश्यक नहीं है। अधिकांश प्रोग्रामर शायद "आकार" को एक अमूर्त वर्ग और "स्क्वायर", "मंडल" आदि के रूप में पहचानते हैं। लेकिन अगर यह तुरंत स्पष्ट नहीं है, तो यह एक उपयोगी संकेत है।

आपको स्थानीय प्रोग्रामिंग सम्मेलनों और स्टाइल गाइड द्वारा भी निर्देशित किया जाना चाहिए।

Answer 5

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

Answer 6

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

Answer 7

किंडा को समझाने में कठोर है, लेकिन मैं केवल इसे क्रियात्मक कक्षाओं में एक ही कोड की प्रतिलिपि बनाने/चिपकाने से रोकने के लिए उपयोग करता हूं, न कि डोमेन ऑब्जेक्ट्स में कुछ।

• AbstractServiceTestCase -> सार उपसर्ग उपयोगी लगता है
• AbstractAnimal -> लगता है अजीब और बेकार

आप बिल्कुल अपने आप के लिए तय करना चाहिए, जब तक कि एक ही सम्मेलन पीछा किया जाता है एक परियोजना भर में ।

Answer 8

अब तक के उत्तर बहुत उपयोगी हैं और अभ्यास के एक जिम्मेदार प्रसार को दिखाते हैं। मैं सहमत हूं कि नामों को कार्यान्वयन का संकेत नहीं देना चाहिए (Foo एक अमूर्त वर्ग हो सकता है जिसे बाद में एक इंटरफेस में ले जाया गया)। हालांकि यह मेरे लिए उपयोगी है जब कोडिंग दृश्य दृश्यों को कोडिंग करने के लिए मुझे व्युत्पन्न कक्षाओं के तरीकों को प्रदान करने की आवश्यकता है।

एक उदाहरण के रूप में वर्तमान में मेरे पास एक हाइयारार्की है (नामों के लिए तर्क के बारे में मत पूछें लेकिन वे संदर्भ में अर्थपूर्ण हैं और XML तत्व नामों पर मानचित्र हैं)।मैं जावा का उपयोग कर रहा है, लेकिन मुझे लगता है कि सबसे अधिक भाषाओं के समान होगा: के बजाय

public abstract class AbstractMarker {...} 
public class Template extends AbstractMarker {...} 
public class Regex extends AbstractMarker {...} 

या

public abstract class AbstractMarker {...} 
public class TemplateMarker extends AbstractMarker {...} 
public class RegexMarker extends AbstractMarker {...} 

public abstract class Marker {...} 
public class TemplateMarker extends Marker {...} 
public class RegexMarker extends Marker {...} 

:

public abstract class Marker {...} 
public class Template extends Marker {...} 
public class Regex extends Marker {...} 

मैं अब की ओर प्रवृत्त कर रहा हूँ

मैं व्यक्तिगत रूप सेयाद कर सकता हूंएक अमूर्त कार्यात्मक अवधारणा है और उप-वर्ग ठोस कार्यान्वयन हैं।

Answer 9

मैं सार कक्षाएं फोन नहीं होगा निम्न कारण सार:

हर आयत एक आकार है। हर जगह आप एक आकार का उपयोग कर सकते हैं, आप एक आयत का उपयोग कर सकते हैं। कोड है कि (लेकिन जो भी मंडलियों के साथ सौदा कर सकते हैं) एक आयत के साथ संबंधित लग सकता है जैसे:

Shape s = .....; 
s.drawTo(myGraphicsContext); 

एक वस्तु (जैसे एक आयत) का उपयोग करते हुए कहीं भी आप इसे का सामान्यीकरण (जैसे एक आकार) का उपयोग कर सकते एक महत्वपूर्ण है ऑब्जेक्ट उन्मुख अवधारणा का हिस्सा, और Liskov Substitution Principle के रूप में जाना जाता है। (यह भी स्पष्ट है: वाक्य या तर्क किस तरह आकार के बारे में बयान होगा, लेकिन फिर नहीं आयतों पर लागू हो?)

आप सामान्यीकरण एक AbstractShape, इस सिद्धांत का उल्लंघन किया है नाम है। एक आयताकार सार सारणी नहीं है। अगर कुछ भी "कंक्रीट आकार" है! एक आयताकार सार नहीं है ("मुझे नहीं पता कि यह किस प्रकार का आकार है। आयताकार हो सकता है, और कुछ और हो सकता है।")। कोड AbstractShape का उपयोग कर तो गलत पढ़ता है:

AbstractShape s = new Rectangle(...); 

मैं इस विषय here के बारे में अधिक विचारों के साथ ब्लॉग।