2009-03-18 11 views
70

Resharper 4.1 का उपयोग करके, मैं इस रोचक चेतावनी में आया हूं: "व्युत्पन्न प्रकार के माध्यम से किसी प्रकार के स्थिर सदस्य तक पहुंच"।किसी व्युत्पन्न प्रकार पर कक्षा के स्थिर सदस्य का उपयोग करना?

class A { 
    public static void SomethingStatic() { 
     //[do that thing you do...] 
    } 
} 

class B : A { 
} 

class SampleUsage { 
    public static void Usage() { 
     B.SomethingStatic(); // <-- Resharper warning occurs here 
    } 
} 

किसी को भी पता है वहाँ क्या मुद्दों कर रहे हैं (यदि हो तो) जब बी के माध्यम से एक के स्थिर सदस्यों का इस्तेमाल कर रही: यहाँ जहां ऐसा होता है की एक कोड नमूना है?

उत्तर

80

एक जगह जहां यह भ्रामक हो सकता है वह स्थिर है जब स्थिर कारखाना विधि है, उदा। WebRequest कक्षा में एक फैक्टरी विधि Create है जो व्युत्पन्न कक्षा के माध्यम से उपयोग किए जाने पर इस प्रकार के कोड को लिखे जाने की अनुमति देगा।

var request = (FtpWebRequest)HttpWebRequest.Create("ftp://ftp.example.com"); 

यहाँ request प्रकार FtpWebRequest की है, लेकिन यह भ्रामक है क्योंकि ऐसा लगता है कि यह एक HttpWebRequest (एक भाई वर्ग) से बनाया गया था, भले ही Create विधि वास्तव में WebRequest (आधार वर्ग) पर परिभाषित किया गया है। निम्नलिखित कोड अर्थ में समान है, लेकिन है स्पष्ट:

var request = (FtpWebRequest)WebRequest.Create("ftp://ftp.example.com"); 

अंत में वहाँ एक व्युत्पन्न प्रकार के माध्यम से एक स्थिर तक पहुँचने में कोई बड़ी समस्या नहीं है, लेकिन कोड अक्सर ऐसा न करने से स्पष्ट है।

+0

यह एक मुद्दा है जिसे मैंने पहले कभी नहीं सोचा था। धन्यवाद ग्रेग! – Swim

+0

एक अच्छा उदाहरण के साथ अच्छा और स्पष्ट स्पष्टीकरण। – serg10

+0

महान स्पष्टीकरण, यह वास्तव में सहायक था। Google पर भी पहला परिणाम ^^ – marcgg

15

यह एक चेतावनी नहीं है, आमतौर पर, केवल एक सुझाव है। आप अनावश्यक रूप से कुछ पर निर्भरता बना रहे हैं।

मान लीजिए कि बाद में आप निर्णय लेते हैं कि बी को ए के उत्तराधिकारी की आवश्यकता नहीं है। यदि आप रिशेर्पर की सलाह का पालन करते हैं, तो आपको कोड की उस पंक्ति को संशोधित करने की आवश्यकता नहीं होगी।

+1

आपको भी उदाहरण विधियों के साथ एक ही समस्या होगी। इस तर्क से, कुछ भी क्यों प्राप्त होता है? या क्या मुझे कुछ याद आ रही है? – NullVoxPopuli

+0

@NullVoxPopuli - ऐसे लोग हैं जो कार्यान्वयन विरासत से पूरी तरह से बचने की सलाह देते हैं। कई लोकप्रिय जावा और सी # किताबें इसका सुझाव देती हैं (यह पेपर भी देखें: http://www.isase.us/wisr3/7.pdf)। लेकिन किसी भी मामले में, यदि आपके पास 'ए' में एक उदाहरण विधि 'Foo' है, तो' बी 'द्वारा संदर्भित' बी 'का एक उदाहरण दिया गया है, तो आपके पास स्थिर स्थिति में समान स्वतंत्रता नहीं है कहें "कहां" 'फू' देखा जाना चाहिए। आपको 'बी' से शुरू करना होगा, जो कुछ भी आप करते हैं। तो यह वास्तव में सांख्यिकी के साथ ही नहीं है। –

2

हाँ मैंने इसे भी देखा है, मैंने हमेशा यह माना है कि यह सिर्फ मुझे चेतावनी दे रहा था क्योंकि यह अनावश्यक था। A.SomethingStatic(); वही काम करेगा।

29

B.SomethingStatic() यह बयान देता है कि SomethingStaticB का सदस्य है। यह सच नहीं है। SomethingStatic स्पष्ट रूप से A का सदस्य है। तथ्य यह है कि B के सदस्यों के लिए यह अयोग्य है (जैसे कि यह B का सदस्य था) सुविधा का विषय है। तथ्य यह है कि B के साथ योग्य होने पर यह पहुंच योग्य है, आईएमओ, एक गलती है।

+2

+1 आईएमओ, आपका स्पष्टीकरण यहां सबसे अच्छा है। –

+0

मुझे लगता है कि एक सबक्लास हमेशा सुपरक्लास की हर संपत्ति का उत्तराधिकारी होना चाहिए। विशेष रूप से परियोजना के लिए मैं अभी पर हूं, यह कारखाने के पैटर्न के साथ बहुत उपयोगी है। – NullVoxPopuli

+0

मैं असहमत हूं। वर्तमान व्यवहार लाभकारी होने पर मेरे पास एक वैध मामला है।यहां विचार है: 'क्लास वैलिडेटर: वैलिडेटरबेस <थ्रोस्ट्रेटी> {} '। उपयोग: 'वैलिडेटर। चेकनऑन्यूक्टी (स्ट्र) '। इसकी तुलना 'ValidatorBase से करें। जांच करें (str) '। – Gebb

संबंधित मुद्दे