@staticmethod बनाम मॉड्यूल-स्तरीय फ़ंक्शन


21

इस बारे में नहीं है @staticmethodऔर @classmethod! मुझे पता है कि कैसे staticmethodकाम करता है। जो मैं जानना चाहता हूं वह @staticmethodबनाम मॉड्यूल-स्तरीय फ़ंक्शन के लिए उचित उपयोग के मामले हैं ।

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

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

या तो स्थैतिकमॉडल या मॉड्यूल स्तर के कार्यों का उपयोग करने के लिए कोई सामान्य नियम-से-अंगूठे हैं? उनके पास क्या ठोस फायदे या नुकसान हैं (उदाहरण के लिए भविष्य का विस्तार, बाहरी विस्तार, पठनीयता)? यदि संभव हो तो, एक उदाहरण उदाहरण भी प्रदान करें।

जवाबों:


11

तकनीकी रूप से एक स्थिर विधि और एक मॉड्यूल फ़ंक्शन बहुत अधिक पहचान का व्यवहार करता है - दोनों ही मामलों में वे मानक कार्यों की तरह काम करते हैं, अंतर नामस्थान जहां वे रखे जाते हैं। इसलिए निर्णय अधिक स्थिरता / पठनीयता में से एक है।

आम तौर पर मैं एक स्थैतिक विधि का उपयोग करता हूं अगर इनमें से कुछ या सभी मानदंड पूरे होते हैं:

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

0

एक कार्यक्रम वास्तविकता के एक टुकड़े का अनुकरण है। इस तरह, यह इस बात पर निर्भर करता है कि आप वास्तविकता को कैसे समझते हैं।

एक फ़ंक्शन कुछ गतिविधि का प्रतिनिधित्व करता है। जितना अधिक गतिविधि सामान्य है, उतना ही बड़ा कार्य गतिविधि को अनुकरण करने की प्रवृत्ति है। विधियाँ कक्षाओं के लिए बाध्य हैं। जितना अधिक गतिविधि वर्ग के लिए विशिष्ट है, उतना ही यह एक विधि द्वारा अनुकरण किया जाता है।

त्रिकोणमितीय कार्यों के बारे में सोचें। कहते हैं, sin()यह बहुत अच्छी तरह से ज्ञात है कि आप जानते हैं कि यह कोण के साथ फिट बैठता है। आप जानते हैं कि यह एक फ्लोट नंबर इनपुट के रूप में चाहता है और फ्लोट लौटाता है। वैसे भी, एक वर्ग द्वारा प्रतिनिधित्व किया जाने वाला एक कोण डेटाटाइप .sin()हो सकता है और बिना तर्क के एक सामान्य विधि हो सकती है जो कोण ऑब्जेक्ट के साथ काम करती है, और .sin(x)एकल तर्क के साथ कक्षा का एक स्थिर तरीका हो सकता है। मैं शर्त लगा सकता हूं कि अधिक लोग सोचते हैं कि sin()सादे कार्य करना बेहतर है । इनका उपयोग अधिक होता है।

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


0

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

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


2
अगर मैं तुम होते तो मैं पहले व्यक्ति में जवाब देने से बचता। यह भ्रमित करने वाला है। आपको इसके बजाय दूसरे व्यक्ति से प्रश्नकर्ता को लिखना चाहिए।
हारून हॉल

शायद। मैं एक उदाहरण उपयोग मामला प्रदान कर रहा था, जो कि पूछने वाले के दिमाग में हो या नहीं हो सकता है।
डीवीडी अविन्स
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.