2010-01-29 12 views
8

मैं कुछ कोड रीफैक्टर कर रहा हूं और मैं एचएफइल नामक एक कक्षा को देख रहा हूं। एचएफआईएल में सभी निजी निर्माता हैं ताकि आप वास्तव में इसके उदाहरण नहीं बना सकें। इसके बजाय इस प्रकार HFiles के उदाहरण बनाने की:स्टेटिक विधि ओवरयूज से बचने के लिए टिप्स

var file = new HFile('filename') 
file.Save() 

सभी HFile बातचीत स्थिर विधियों के माध्यम से नियंत्रित किया जाता है। तो अगर मैं एक फ़ाइल को बचाने के लिए करना चाहता था मैं कहेंगे:

HFile.save('filename') 

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

+3

टैग या भाषा को टैग में रखना एक अच्छा विचार होगा। –

उत्तर

5

सामान्य तौर पर, अपनी स्थिति राज्य या एक संगठनात्मक संरचना की कैप्सूलीकरण की आवश्यकता है, तो आप वर्गों का उपयोग किया जाएगा।

दूसरी ओर, यदि आप कुछ है कि एक पार काटने चिंता का विषय है, और अपने आवेदन भर में मोटे तौर पर इस्तेमाल किया जा सकता है, तो आप एक स्थिर उपयोगिता कक्षा में तरीकों पर विचार हो सकता है। .NET Framework (और जावा) में System.Math इसका एक उदाहरण है।

अपने उदाहरण में, HFile शायद राज्य के साथ एक वस्तु है, इसलिए मैं आम तौर पर इसे सहेजने के लिए एक स्थिर विधि का उपयोग नहीं होता। सहेजने के लिए एक संपूर्ण विधि को पार करने के बजाय, संपूर्ण एचएफआईएल ऑब्जेक्ट पर एक विधि कॉल करने के लिए बस इतना आसान है। चाहे वह आपके विशेष आवेदन में समझ में आता है या नहीं, इस पर निर्भर करता है कि आपके एप्लिकेशन का प्रतिमान एचएफआईएल ऑब्जेक्ट्स को चारों ओर पारित करने और बाहरी तरीकों से कार्य करने के लिए या स्वयं को बचाने में सक्षम स्टैंडअलोन ऑब्जेक्ट्स के रूप में देखता है या नहीं।

5

स्टेटिक विधियों का परीक्षण करना मुश्किल है क्योंकि आप उन्हें नकल नहीं कर सकते हैं। इस कारण से हम उन्हें अपने काम के स्थान पर टालना चाहते हैं। हालांकि हम कारखाने के तरीकों के लिए उनका उपयोग करते हैं।

+0

मैं यह जोड़ना चाहता हूं कि उस स्थिर फैक्ट्री विधियों को कक्षा में उपयोग करने के लिए ठीक है जो आपकी सभी निर्भरताओं (जैसे गुइस @ प्रावधान विधियों) को तत्काल करता है, लेकिन नियमित कोड में स्थैतिक फैक्ट्री विधियों का उपयोग करके टेस्टेबिलिटी को नुकसान पहुंचाता है, क्योंकि सामान्य स्थिर तरीकों का उपयोग करने की तरह, वे अपने कोड को एक विशेष कार्यान्वयन का उपयोग करके लॉक करें और निर्भरता का मज़ाक उड़ाते हुए आपको रोक देगा। – MageWind

2

यह बहुत ऑब्जेक्ट उन्मुख नहीं है, है ना। अब शायद आपकी जगह ओओ कोड पसंद नहीं है, और यह ठीक है। लेकिन यदि आप डेटा और विधियों को समाहित करना चाहते हैं, तो आपको उस डेटा पर काम करने के लिए उदाहरण विधियों की आवश्यकता है।

स्थिर तरीकों की प्रचुरता शायद वैश्विक चर के बहुत सारे के साथ जुड़ा हुआ है। उदाहरण के लिए। अगर आप एक स्थिर HFile.save ('filename') को कॉल करने जा रहे हैं, तो फ़ाइल फ़ाइल में सहेजने की कोशिश करने वाली जानकारी वैश्विक होनी चाहिए। आम तौर पर हम चीजों को और अधिक प्रबंधनीय रखने के लिए ग्लोबल्स को कम करने की कोशिश करते हैं।

लेकिन अगर आप प्रक्रियात्मक कोड लिखना चाहते हैं, तो यह ठीक है। एक वस्तु उन्मुख भाषा में प्रक्रियात्मक कोड लिखने -

+1

स्थिर तरीके महान लोडर (फैक्ट्री विधि का एक प्रकार) बनाते हैं। मुझे अन्य प्रक्रियाओं को पकड़ने से बचने के लिए संसाधन ताले के आसपास उनका उपयोग करना बहुत उपयोगी लगता है। –

10

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

+1

स्थैतिक तरीकों के लिए टेस्ट लिखने के लिए सबसे आसान हैं, बशर्ते आप कोई स्थिर स्थिति न रखें। –

+2

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

+0

वे एकमात्र प्रकार की स्थैतिक विधियां हैं जिन्हें मैं लिखता हूं। एक प्रतिनिधि उदाहरण के लिए .NET ढांचे में गणित वर्ग को देखें। –

2

आईएमओ स्थैतिक विधियां आपके कार्यस्थल पर सामान्य उद्देश्य के लिए उपयोगी नहीं हैं। इस विधि के नुकसान:
- किसी ऑब्जेक्ट को बनाने का बिंदु क्या है जो किसी फ़ाइल को संदर्भित करता है ताकि अनिवार्य रूप से केवल एक विधि को कॉल किया जा सके?
- उपयोग नहीं कर सकते इंटरफेस आधारित बहुरूपता

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

3

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

+0

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

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