2010-09-13 12 views
11

मैंने अक्सर इस पर विचार किया है ... शायद यह एक बेवकूफ सवाल है लेकिन यहां जाता है।क्या मुझे हमेशा अपनी विधियों को यथासंभव स्थिर बनाना चाहिए?

public class SomeClass 
{ 
    public int AProperty { get; set; } 

    public void SomeMethod() 
    { 
     DoStuff(AProperty); 
    } 
} 

कोई फायदा ऐसा करने के लिए है:

public class SomeClass 
{ 
    public int AProperty { get; set; } 

    public static void SomeMethod(int arg) 
    { 
     DoStuff(arg); 
    } 
} 

केवल लाभ यह है कि स्पष्ट है कि मैं अब सीधे SomeMethod का उपयोग कर सकते है

मैं इस वर्ग है कहो।

तो क्या इस तरह के तरीकों को स्थैतिक बनाना अच्छा अभ्यास है जहां थोड़ा रिफैक्टरिंग अनुमति देगी या यह मेरे समय का अपशिष्ट है?

संपादित करें: मैं (और ShellShock की टिप्पणी मुझे याद दिलाया) का उल्लेख है कि कारण मैं पूछता हूँ कि मैं ReSharper का उपयोग है भूल गया और यह हमेशा सुझाव है कि 'विधि एक्स स्थिर किया जा सकता है' और इतने पर बनाता है ...

+0

[स्टेटिक बनाम गैर स्थैतिक विधि] के संभावित डुप्लिकेट (http://stackoverflow.com/questions/1184701/static-vs-non-static-method) –

+0

यदि विधि को आवृत्ति विशिष्ट डेटा की आवश्यकता नहीं है इसे स्थिर बना सकते हैं। – halfdan

+0

मुझे आधादान पता है, लेकिन मैं पूछ रहा हूं - क्या मुझे चाहिए? – Nobody

उत्तर

15

स्टेटिक बुरा नहीं है। अगर हमारे प्रोग्रामिंग टूलकिट के कई हिस्सों की तरह गलत तरीके से इस्तेमाल किया जाता है तो स्टेटिक बुरा होता है।

स्टेटिक बहुत फायदेमंद हो सकता है। the accepted answer here बताते हैं, स्थिर में संभावित गति सुधार हो सकता है।

एक सामान्य नियम के रूप में यदि विधि का उपयोग नहीं किया जा रहा है और कक्षा के क्षेत्र हैं तो इसके कार्य का मूल्यांकन करने के लिए यह एक अच्छा समय है, हालांकि आखिरकार उपयोगिता विधियों को किसी ऑब्जेक्ट को तत्काल किए बिना बुलाया जा सकता है। उदाहरण के लिए DirectoryInformation और FileInformation कक्षाओं में उपयोगी स्थिर विधियां हैं।

संपादित

का कहना है कि यह एक बहुत कठिन मजाक पड़ता है बाध्य लग रहा है, लेकिन यह अभी भी निश्चित रूप से परीक्षण योग्य है।

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

1

सं। Static is evil। यह कॉलर को इस्तेमाल किए गए वर्ग और makes it hard to test पर कसकर जोड़ता है।

+1

माइक्रोसॉफ्ट के कोड विश्लेषण उपकरण हमेशा यह सुझाव दे रहे हैं कि यदि कोई आवृत्ति निर्भरता नहीं है तो मुझे विधियों को स्थैतिक बनाना चाहिए। क्या यह बुरी सलाह है? – Polyfun

+0

@ शेलशॉक हो सकता है। यदि आपके पास ऐसी कई विधियां हैं, तो संभवतः आप ओओपी सिद्धांतों का उल्लंघन करते हैं। किसी ऑब्जेक्ट की विधि (लगभग) ऑब्जेक्ट से जुड़े डेटा के साथ हमेशा काम करना चाहिए। –

+0

@dark_charlie: तो आप जो कहते हैं वह यह है कि यदि आपके पास स्थिर के रूप में कोई विधि हो सकती है, तो आपको इसके बजाय एक स्थिर उपयोगिता कक्षा में इसे बाहर निकालने के लिए पुनर्गठन करना चाहिए? क्या होगा यदि विधि क्लासिक से क्लासिक रूप से बंधी गई है, लेकिन तकनीकी रूप से किसी भी सदस्य का उपयोग नहीं कर रही है? – awe

1

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

उदाहरण के लिए, कहें कि आपके पास स्ट्रिंग क्लास और दो स्ट्रिंग्स ए और बी हैं। ए और बी की तुलना करने के लिए, आप या तो ए कॉम्पारे (बी) विधि या स्ट्रिंग कर सकते हैं। कॉम्पारे (ए, बी) तरीका।

अगर मैं गलत हूं तो कृपया मुझे सही करें।

+0

मुझे लगता है कि 'XDocument.Parse' एक बेहतर उदाहरण होगा। XDocument बनाने में बहुत अधिक बिंदु नहीं होगा, जो कि आप वास्तव में चाहते हैं कि XDocument बनाने के लिए अपने पार्स विधि का उपयोग करने के लिए। –

2

स्टेटिक विधियां समझ में आती हैं, अगर आप उन्हें पहले कक्षा के ऑब्जेक्ट के बिना कॉल करने में सक्षम होना चाहिए। जावा में, उदाहरण के लिए, मैथ-क्लास में केवल स्थिर विधियां होती हैं, क्योंकि यह अन्य वस्तुओं पर गणितीय परिचालन करने के लिए केवल गणित-वर्ग को इंस्टाल करने के लिए अधिक समझ नहीं लेती है।

अधिकांश समय स्थिर तरीकों से बचने के लिए बेहतर होता है। आपको ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग से परिचित होना चाहिए - वहां बहुत सारे अच्छे संसाधन हैं, स्थिर विधियों जैसे सभी अवधारणाओं को समझाते हुए,

2

मैं आपके द्वारा प्रदान किए गए कोड नमूने से जुड़े अपने विशिष्ट प्रश्न का उत्तर देने का प्रयास करूंगा।

यदि SomeMethod केवल उस वर्ग में उपयोगी है जिसे घोषित किया गया है, तो मैं स्थिर रूपांतरण से बचूंगा और इसे एक उदाहरण विधि के रूप में छोड़ दूंगा।

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

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

एक (बहुत सरल) उदाहरण है, जहां एक स्थिर बुराई है, लेकिन एक गैर बुराई संस्करण के लिए परिवर्तित किया जा सकता के लिए, एक समारोह है कि किसी की उम्र की गणना करता है की कल्पना:

static TimeSpan CalcAge(DateTime dob) { return DateTime.Now - dob; } 

कि परीक्षण योग्य है? जवाब न है। यह बड़े पैमाने पर अस्थिर स्थिर स्थिति पर निर्भर करता है जो DateTime.Now है। आपको हर बार एक ही इनपुट के लिए एक ही आउटपुट की गारंटी नहीं है। इसे और अधिक परीक्षण के अनुकूल बनाने के लिए:

static TimeSpan CalcAge(DateTime dob, DateTime now) { return now - dob; } 

अब सभी मूल्यों समारोह पर निर्भर करता है में पारित कर रहे हैं, और यह पूरी तरह से परीक्षण योग्य है। एक ही इनपुट आपको एक ही आउटपुट प्राप्त करेगा।

+0

आप कहते हैं कि यदि विधि केवल कक्षा के भीतर उपयोगी है, तो इसे स्थिर न करें। क्या यह एक विधि स्थिर बनाकर भी हासिल नहीं किया गया है? अन्यथा 'निजी स्थिर' विधि (जो संभव है, और वास्तव में ReSharper द्वारा सुझाया गया) होने का क्या मतलब होगा? – awe

+0

@awe - आप सही हैं कि स्थिर विधियों को कॉल करना तेज होना चाहिए। हालांकि, मुझे लगता है कि इस विशिष्ट उदाहरण के लिए 'someClassInstance.SomeMethod()' को कॉल करना 'SomeClass.SomeMethod (someClassInstance.aproperty)' से बेहतर है। मुझे नहीं लगता कि प्रश्न में सुझाए गए रिफैक्टर सबसे अच्छी बात है - कई अन्य मामलों में यह है। क्या रीशर्पर सुझाव देता है कि ऊपर दिए गए उदाहरण के लिए रिफैक्टर? यह मुझे आश्चर्यचकित करेगा अगर ऐसा होता है क्योंकि विधि एक आवृत्ति संपत्ति तक पहुंच जाती है। आप पूरे हॉग पर जा सकते हैं और यदि आप चाहें तो * सभी * आपके गैर वर्चुअल इंस्टेंस विधियों के लिए 'स्थिर कुछ विधि (कुछ क्लास इसे) लिखें। –

+0

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

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

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