क्या मैं सभी स्थिर तरीकों का उपयोग नहीं कर सकता / सकती?


64

नीचे दिए गए दो UpdateSubject तरीकों में क्या अंतर है? मुझे लगा कि यदि आप सिर्फ संस्थाओं पर काम करना चाहते हैं तो स्थैतिक तरीकों का उपयोग करना बेहतर है। मुझे गैर-स्थैतिक विधियों के साथ किन स्थितियों में जाना चाहिए?

public class Subject
{
    public int Id {get; set;}
    public string Name { get; set; }

    public static bool UpdateSubject(Subject subject)
    {
        //Do something and return result
        return true;
    }
    public bool UpdateSubject()
    {
        //Do something on 'this' and return result
        return true;
    }
}

मुझे पता है कि मुझे इस वास्तव में कष्टप्रद प्रश्न के लिए समुदाय से कई किक मिल रही होंगी लेकिन मैं खुद को यह पूछने से रोक नहीं पाया।

क्या विरासत के साथ काम करते समय यह अव्यवहारिक हो जाता है?

अद्यतन:
इसके हमारे कार्य स्थल पर अब हो रहा है। हम 5 डेवलपर्स के साथ 6 महीने के asp.net वेब एप्लिकेशन पर काम कर रहे हैं। हमारे वास्तुकार ने फैसला किया कि हम सभी एपीआई के लिए सभी स्थिर तरीकों का उपयोग करते हैं। उनके तर्कपूर्ण तरीके स्थिर होने के कारण हल्के वजन के होते हैं और यह सर्वर लोड को कम करके वेब अनुप्रयोगों को लाभ पहुंचाता है।


9
रिच हिकी कुछ गैर-मुहावरेदार को प्रोत्साहित करेगा जैसे (सभी स्थिर तरीके)। यदि आप एक कार्यात्मक शैली पसंद करते हैं, तो आप एक कार्यात्मक भाषा का उपयोग भी कर सकते हैं;) सॉफ्टवेयर में सब कुछ एक वस्तु के रूप में सबसे अच्छा नहीं है।
जॉब

13
@ जोब: मैं वास्तव में नहीं देखता कि यह कैसे कार्य करता है - यह प्रक्रियात्मक है।
एरोन

2
@ जोब: यह वर्ग अपरिवर्तनीय नहीं है।
आरयू 4-0

3
@ डोनलफ्लो: बेशक आप कर सकते हैं, C # और F # दोनों मिश्रित प्रतिमान हैं। लेकिन तथ्य यह है, स्थिर तरीके! = कार्यात्मक प्रोग्रामिंग। एफपी का अर्थ है पासिंग / चेनिंग फ़ंक्शंस, अपरिवर्तनीय डेटा प्रकार, साइड-इफ़ेक्ट से बचाव, आदि जो ओपी में कोड स्निपेट के विपरीत है।
हारून

4
"उनके तर्कपूर्ण तरीके स्थिर होने के कारण हल्के वजन के होते हैं और यह सर्वर लोड को कम करके वेब अनुप्रयोगों को लाभ पहुंचाता है"। यह गलत है। सर्वर लोड को कम रखने?
mamcx

जवाबों:


87

मैं स्पष्ट "इस" मापदंडों के साथ स्थिर तरीकों की सबसे स्पष्ट समस्याओं के साथ जाऊंगा:

  1. आप आभासी प्रेषण और बाद में बहुरूपता खो देते हैं। आप उस पद्धति को एक व्युत्पन्न वर्ग में कभी भी ओवरराइड नहीं कर सकते। बेशक आप एक व्युत्पन्न वर्ग में एक new( static) विधि की घोषणा कर सकते हैं , लेकिन कोई भी कोड जो इसे एक्सेस करता है उसे पूरे वर्ग पदानुक्रम के बारे में पता होना चाहिए और स्पष्ट जाँच और कास्टिंग करना चाहिए, जो कि ओओ से बचने के लिए माना जाता है ।

  2. # 1 के विस्तार के आधार पर, आप क्लास के उदाहरणों को इंटरफ़ेस से नहीं बदल सकते , क्योंकि इंटरफेस (अधिकांश भाषाओं में) staticतरीकों की घोषणा नहीं कर सकते हैं ।

  3. अनावश्यक क्रिया। कौन सा अधिक पठनीय है: Subject.Update(subject)या बस subject.Update()?

  4. तर्क की जाँच। फिर से भाषा पर निर्भर करता है, लेकिन कई यह सुनिश्चित करने के लिए एक अंतर्निहित जांच संकलित करेंगे कि thisतर्क nullएक अशक्त संदर्भ बग को असुरक्षित रनटाइम स्थिति (एक बफर ओवररन का प्रकार) बनाने से रोकने के लिए नहीं है। उदाहरण के तरीकों का उपयोग नहीं करते हुए, आपको प्रत्येक विधि की शुरुआत में स्पष्ट रूप से इस चेक को जोड़ना होगा।

  5. यह भ्रमित करने वाला है। जब एक सामान्य, उचित प्रोग्रामर एक staticविधि देखता है , तो वह स्वाभाविक रूप से यह मानने वाला है कि उसे एक वैध उदाहरण की आवश्यकता नहीं है (जब तक कि यह एक तुलना या समानता विधि की तरह कई उदाहरण न ले, या nullसंदर्भों पर काम करने में सक्षम हो ) । इस तरीके का उपयोग करते हुए स्थैतिक तरीकों को देखकर हमें एक दोहरा या शायद ट्रिपल लेने वाला है, और 4 या 5 वें समय के बाद हम तनावग्रस्त और नाराज होने वाले हैं और भगवान आपकी मदद करते हैं यदि हम आपके घर का पता जानते हैं।

  6. यह दोहराव का एक रूप है। जब आप किसी इंस्टेंस विधि को लागू करते हैं तो वास्तव में क्या होता है कि कंपाइलर या रनटाइम टाइप की विधि तालिका में विधि को देखता है और thisएक तर्क के रूप में इसका उपयोग करता है। आप मूल रूप से कंपाइलर पहले से ही लागू कर रहे हैं। आप DRY का उल्लंघन कर रहे हैं , एक ही पैरामीटर को बार-बार अलग-अलग तरीकों से दोहरा रहे हैं जब इसकी आवश्यकता नहीं होती है।

स्थैतिक तरीकों के साथ उदाहरण के तरीकों को बदलने के लिए किसी भी अच्छे कारण की कल्पना करना मुश्किल है । कृपया नहीं।


5
आपकी अंतिम पंक्ति के लिए +1। मैं चाहता हूं कि बहुत से लोग "स्थैतिक विधि" को "स्थिर विधि" से पहले सोचेंगे।
स्टुअर्ट लीलैंड-कोल

4
+1। मैं उस स्थैतिक तरीकों को जोड़ूंगा, जिससे परीक्षण लिखना कठिन हो सकता है, क्योंकि ज्यादातर मामलों में आप उनका मजाक नहीं उड़ा सकते हैं: एक बार आपके कोड का कोई भी हिस्सा स्थैतिक विधि पर निर्भर करता है, तो आप इसे नहीं के साथ प्रतिस्थापित कर सकते हैं- आपके परीक्षणों में शामिल हैं। .NET दुनिया में एक प्रमुख उदाहरण कक्षाओं की तरह होगा File, FileInfoऔर DirectoryInfo(वास्तव में, ऐसे पुस्तकालय हैं जो उन्हें इंटरफेस के पीछे छिपाते हैं जिन्हें तब आवश्यकतानुसार इंजेक्ट किया जा सकता है और परीक्षण में नकली किया जा सकता है)।
एस.एम.

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

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

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

13

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


एफडब्ल्यूआईडब्ल्यू, सी के साथ आप इस तरह से वर्चुअल डिस्पैच कर सकते हैं: obj->type->mthd(obj, ...);और यह काफी हद तक अन्य भाषाओं में वर्चुअल डिस्पैच के साथ होता है (लेकिन पर्दे के पीछे)।
डोनाल्ड फैलो

@ कार्ल क्या आप गहरी खुदाई शुरू करने के लिए किसी प्रकार का लिखित संदर्भ प्रदान कर सकते हैं?
जोर्ज ल्वीन

आप एक अच्छे संदर्भ कार्यान्वयन के रूप में GObject को देखना चाहते हैं ।
कार्ल बेज़ेलफेल्ट

10

स्थैतिक विधि के साथ समस्या वह क्षण आती है जब आपको एक उप-वर्ग की आवश्यकता होती है।

उप-वर्गों में स्थिर तरीकों को ओवरराइड नहीं किया जा सकता है, इसलिए आपकी नई कक्षाएं विधियों के नए कार्यान्वयन प्रदान नहीं कर सकती हैं, जिससे वे कम उपयोगी हो जाते हैं।


2
यह जरूरी एक समस्या नहीं है। कुछ भाषाएं जानबूझकर समान कार्य को पूरा करने के लिए अन्य तंत्र (C ++ और C # में गैर-आभासी तरीके) प्रदान करती हैं - C # यहां तक ​​कि इस विचार को आगे बढ़ाने के लिए "सील" तरीके प्रदान करता है! जाहिर है, आप ऐसा सिर्फ इसके लिए नहीं करेंगे, लेकिन इसके बारे में पता होना एक अच्छी तकनीक है ...
Shog9

@Steve, वह जगह नहीं है, क्योंकि आप अभी भी दोनों तरीकों को सीधे कॉल कर सकते हैं।

@ स्थिर, जावा स्थिर विधियों में ओवरराइड नहीं किया जा सकता है।

@ Thorbjørn - सबसे पहले, सवाल जावा, या किसी अन्य विशिष्ट ओओपी भाषा को टैग नहीं किया गया है। इससे भी महत्वपूर्ण बात, मैंने यह नहीं कहा कि आप एक स्थिर सदस्य फ़ंक्शन को ओवरराइड कर सकते हैं। मैं एक बिंदु बनाने के लिए एक सादृश्य का उपयोग करने की कोशिश कर रहा था। जैसा कि मैंने स्पष्ट रूप से विफल रहा, टिप्पणियों को हटा दिया।
21347 पर स्टीव 314

2
एक अर्थ में, ये अभी भी "विधियों का नया कार्यान्वयन" हैं। बस मानक OOP अर्थों में नहीं। ऐसा लगता है जैसे मैं कह रहा हूँ "आपका शब्द या तो बिल्कुल सही नहीं है, नर्स-नर्स-ना-नर्स-नर्सिंग ... ;-)
स्टीव 314

7

यदि आप एक विधि घोषित staticकरते हैं, तो आपको विधि newको निष्पादित करने के लिए वर्ग ( कीवर्ड का उपयोग करके ) से एक ऑब्जेक्ट को तुरंत नहीं करना होगा । हालाँकि, आप किसी भी सदस्य चर का उल्लेख नहीं कर सकते हैं जब तक कि वे भी स्थिर नहीं होते हैं, उस स्थिति में वे सदस्य चर वर्ग के होते हैं, वर्ग के विशिष्ट तात्कालिक वस्तु नहीं।

एक और तरीका रखो, staticकीवर्ड कक्षा की परिभाषा का हिस्सा होने के लिए एक घोषणा का कारण बनता है, इसलिए यह कक्षा के सभी उदाहरणों में एक एकल संदर्भ बिंदु बन जाता है ( वर्ग से त्वरित वस्तुएं)।

यह इस प्रकार है, कि यदि आप अपनी कक्षा की कई चल रही प्रतियाँ चाहते हैं, और आप नहीं चाहते हैं कि राज्य (सदस्य चर) को आपकी सभी चल रही प्रतियों के बीच साझा किया जाए (अर्थात प्रत्येक वस्तु अपनी विशिष्ट स्थिति रखती है), तो आप उन सदस्य चर को स्थिर घोषित नहीं कर सकते।

सामान्य तौर पर, आपको staticकक्षाओं और विधियों का उपयोग केवल तब करना चाहिए जब आप उपयोगिता के तरीके बना रहे हों जो एक या अधिक मापदंडों को स्वीकार करते हैं, और किसी प्रकार की वस्तु लौटाते हैं, बिना किसी दुष्प्रभाव के (अर्थात कक्षा में राज्य चर में परिवर्तन)


1
मैं ओपी को समझता हूं कि staticइसका क्या मतलब है, वह पूछ रहा है कि क्यों न सब कुछ स्थिर घोषित किया जाए।
एड एस।

1
वह है का एक उदाहरण में गुजर Subjectनिहित के बजाय लेकिन कोई स्पष्ट पैरामीटर के रूप में, - thisपैरामीटर।
स्टीव314

ठीक है, हाँ ... लेकिन मुझे नहीं लगता कि मैं आपकी बात मानता हूँ।
एड एस।

@ ईडी - केवल इतना है कि आप एक स्पष्ट पैरामीटर के माध्यम से बहुत कुछ कर सकते हैं जो आप एक अंतर्निहित thisपैरामीटर के माध्यम से कर सकते हैं । उम्मीदों में अंतर है, लेकिन विरासत के बाहर, आप क्या कर सकते हैं , इसमें कोई वास्तविक अंतर नहीं है। उदाहरण के लिए, उन गैर-स्थैतिक सदस्यों तक पहुँचा जा सकता है - स्पष्ट पैरामीटर के माध्यम से।
233 पर स्टीव314

मैं इस धारणा के तहत काम कर रहा था कि आप सी # में तर्क के निजी सदस्यों को एक ही कक्षा में घोषित स्थिर विधि के माध्यम से नहीं प्राप्त कर सकते हैं (जैसा कि आप सी ++ में कर सकते हैं)। यकीन नहीं होता कि मैंने ऐसा क्यों सोचा, लेकिन मैं गलत था।
एड एस।

3

लोगों का तर्क है कि 'स्थिर तरीके खराब डिजाइन दिखाते हैं' जरूरी नहीं कि विधियों के कारण, यह वास्तव में स्थिर डेटा है, निहित या स्पष्ट है। निहितार्थ से मेरा तात्पर्य उस कार्यक्रम के किसी भी राज्य से है जो रिटर्न वैल्यू या मापदंडों में निहित नहीं है। एक स्थिर कार्य में राज्य को संशोधित करना प्रक्रियात्मक प्रोग्रामिंग के लिए एक फेंक है। हालाँकि, यदि फ़ंक्शन राज्य को संशोधित नहीं करता है, या घटक ऑब्जेक्ट फ़ंक्शन के लिए राज्य संशोधन को दर्शाता है, तो यह वास्तव में प्रक्रियात्मक की तुलना में अधिक कार्यात्मक प्रतिमान है।

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

अंततः 'स्टेट मैनजर' और स्थिर या वैश्विक डेटा जैसी आमतौर पर देखी जाने वाली ओवरसाइज़्ड वस्तुओं के बीच व्यवहार में कोई अंतर नहीं है। सही तरीके से उपयोग किए जाने वाले स्थिर तरीकों का लाभ यह है कि वे लेखक के इरादे को बाद में संशोधित करने के लिए राज्य को संशोधित नहीं करने का संकेत दे सकते हैं।


1
आपका कथन "... प्रक्रियात्मक प्रोग्रामिंग के लिए एक थकाऊ है ..." मुझे लगता है कि आप इसे बहुत बुरा मानते हैं, मुझे लगता है कि यह एक अर्थ में ओओ का हिस्सा है।
NoChance

making ... unit testing much easier.नहीं, यह नहीं होगा। यह ऐसा कोई भी कोड बनाता है जो स्थिर तरीकों को इकाई परीक्षण के लिए असंभव कहता है , क्योंकि आप इसे स्थैतिक विधि से अलग नहीं कर सकते हैं। स्थैतिक विधि के लिए एक कॉल उस वर्ग के लिए एक हार्डकोड निर्भरता बन जाता है।
स्टुपेरयूज़र

2

भाषा और आप जो करने की कोशिश कर रहे हैं, उसके आधार पर, इसका उत्तर यह हो सकता है कि बहुत अंतर नहीं है, लेकिन staticसंस्करण में थोड़ा अव्यवस्था है।

जैसा कि आपका उदाहरण वाक्यविन्यास जावा या सी # का सुझाव देता है, मुझे लगता है कि थोरबजर्न रावन एंडरसन ओवरराइडिंग (देर से बाध्यकारी के साथ) मुद्दे को इंगित करना सही है। स्थैतिक विधि के साथ, देर से बाध्यकारी के लिए कोई "विशेष" पैरामीटर नहीं है, इसलिए आप देर से बाध्यकारी नहीं हो सकते।

वास्तव में, एक स्थिर विधि एक मॉड्यूल में एक फ़ंक्शन है, उस मॉड्यूल का वर्ग के समान नाम है - यह वास्तव में बिल्कुल एक OOP विधि नहीं है।


2

जब आप ऐसा करते हैं तो आप मूल रूप से वस्तुओं के पूरे बिंदु को हरा देते हैं। वहाँ एक अच्छा कारण है कि हम बहुत ज्यादा प्रक्रियात्मक कोड से वस्तु उन्मुख कोड में स्थानांतरित कर दिया है।

मैं कभी भी एक स्थिर विधि की घोषणा नहीं करूंगा जो कक्षा के प्रकार को एक पैरामीटर के रूप में लेती है। यह बिना किसी लाभ के कोड को अधिक जटिल बनाता है।


3
आप इसे कर सकते हैं यदि आप objectएक staticविधि से गुजर रहे थे , और एक नया लौटा रहे थे object। कार्यात्मक प्रोग्रामर हर समय ऐसा करते हैं।
रॉबर्ट हार्वे

प्रश्न: क्या आप Mathस्थैतिक वर्ग को "बिना किसी लाभ के लिए जटिल मानते हैं ", या क्या आप इसे पसंद करेंगे यदि सभी प्रकार के आभासी तरीकों में निरपेक्ष मूल्य, ऋणात्मकता, जोड़, चुकता, मनमानी जड़ें और इतने पर परिभाषित किया गया हो? मुझे ऐसा नहीं लगता। जब आप छिपे हुए परिवर्तनशील राज्य को संग्रहीत करने की आवश्यकता होती है, तो वस्तुएं साफ-सुथरी होती हैं, जहां आपको कुछ अपरिवर्तनीयों को लागू करने की आवश्यकता होती है। एक प्रकार पर चलने वाले हर निर्णायक विधि को एक साथ टाइप करना, यह कुछ ऐसा है जो जटिल और अचूक कोड की ओर ले जाता है। मैं रॉबर्ट से सहमत हूं, आप देख सकते हैं कि प्रोग्रामर कैसे काम करते हैं, यह एक वास्तविक आंख खोलने वाला हो सकता है!
सारा

@kai जैसा कि मैंने कहा, बहुत ज्यादा। गणित वर्ग एक उचित अपवाद है, हालांकि इसे संख्यात्मक प्रकारों से जोड़ना एक बुरा विचार नहीं होगा।
लोरेन Pechtel

2

यहाँ बहुत सारे शानदार उत्तर हैं, और वे बहुत अधिक व्यावहारिक और ज्ञानवर्धक हैं, किसी भी चीज़ की तुलना में मैं कभी भी उत्तर के रूप में आ सकता हूं, लेकिन मुझे लगता है कि कुछ ऐसा है जो शोभा नहीं दे रहा है:

"हमारे वास्तुकार ने फैसला किया कि हम सभी एपीआई के लिए सभी स्थिर तरीकों का उपयोग करते हैं। उनके तर्कपूर्ण तरीके हल्के होने के कारण वजन कम होता है और यह सर्वर लोड को कम करके वेब अनुप्रयोगों को लाभ पहुंचाता है ।"

(बोल्ड जोर मेरा है)

प्रश्न के इस भाग पर मेरा 2c यह है:

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

इस पर शैतान के अधिवक्ता का थोड़ा नाटक: हम आगे भी जा सकते हैं और सामान जैसे:

  • यह वास्तव में बहुत बुरा हो सकता है यदि कोई उदाहरण (उदाहरण) विधि के प्रत्येक आह्वान के लिए बनाया गया है (जैसा कि इसे स्थिर रखने और इस तरह से कॉल करने के विपरीत)

  • कंस्ट्रक्टर की जटिलता के आधार पर, टाइप हाइरार्की, अन्य उदाहरण के सदस्य और ऐसे अन्य अज्ञात कारक, गैर-स्टेटिक विधि कॉल का अतिरिक्त ओवरहेड अलग-अलग हो सकता है और वास्तव में बड़ा हो सकता है

सच में, आईएमएचओ, उपरोक्त बिंदु (और "चलो स्टैटिक्स का उपयोग करते हैं क्योंकि वे तेज़ हैं") का सामान्य दृष्टिकोण स्ट्रॉ मैन तर्क / आश्वासन हैं:

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

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


2

यह एक बहुत ही दिलचस्प सवाल है जो आपके द्वारा पूछे जा रहे समुदाय के आधार पर बहुत अलग उत्तर देता है। अन्य उत्तर सी # या जावा पूर्वाग्रह प्रतीत होते हैं: एक प्रोग्रामिंग भाषा जो (अधिकतर) शुद्ध वस्तु उन्मुख है और वस्तु उन्मुखता का एक प्रकार का मुहावरेदार दृश्य है।

अन्य समुदायों में, जैसे कि C ++, ऑब्जेक्ट ओरिएंटेशन अधिक उदारता के साथ व्याख्या है। कुछ अच्छी तरह से जानते हैं कि विशेषज्ञों ने इस विषय का अध्ययन किया है और वास्तव में, निष्कर्ष निकाला है कि नि: शुल्क कार्यों में सुधार होता है (जोर मेरा है):

अब हमने देखा है कि एक वर्ग में एनकैप्सुलेशन की मात्रा को मापने का एक उचित तरीका उन कार्यों की संख्या की गणना करना है जो यदि वर्ग के कार्यान्वयन में परिवर्तन होते हैं तो उन्हें तोड़ दिया जा सकता है। ऐसा होने के नाते, यह स्पष्ट हो जाता है कि n सदस्य कार्यों के साथ एक वर्ग n + 1 सदस्य कार्यों के साथ एक वर्ग की तुलना में अधिक समझाया गया है। और वह अवलोकन वही है जो गैर-सदस्य गैर-मित्र कार्यों को सदस्य कार्यों के लिए प्राथमिकता देने के लिए मेरे तर्क को सही ठहराता है

स्कॉट मेयर्स

C ++ शब्दावली से अपरिचित लोगों के लिए:

  • सदस्य समारोह = विधि
  • गैर-सदस्य फ़ंक्शन = स्थिर विधि
  • गैर-मित्र = केवल सार्वजनिक API का उपयोग करें
  • गैर-सदस्य गैर-मित्र फ़ंक्शन = स्थिर विधि जो केवल सार्वजनिक एपीआई का उपयोग करती है

अब, आपको प्रश्न का उत्तर देने के लिए:

क्या मैं सभी स्थिर तरीकों का उपयोग नहीं कर सकता / सकती?

नहीं, आपको हमेशा स्थिर विधियों का उपयोग नहीं करना चाहिए।

लेकिन, आपको उनका उपयोग तब करना चाहिए जब आपको केवल किसी वर्ग के सार्वजनिक एपीआई का उपयोग करने की आवश्यकता हो ।


-3

जावा में ...

स्टैटिक विधियाँ ओवरराइट नहीं की जाती हैं, बल्कि इसके बजाय छिपाई जाती हैं और इसलिए यह कक्षा को बढ़ाने के मामले में एक बड़ा अंतर (समस्या?) होगा।

दूसरी ओर मैंने देखा कि जावा प्रोग्रामर के पास सभी एचएएस ऑब्जेक्ट के बारे में सोचने की प्रवृत्ति है, वास्तव में यह समझने के लिए बिना कि क्यों, और मैं असहमत हूं।

क्लास के लिए विशिष्ट कोड के लिए स्टेटिक का उपयोग किया जाना चाहिए। वंशानुक्रम विरासत के साथ अच्छी तरह से काम नहीं करता है।

स्थिर तरीकों के उपयोग के कुछ अच्छे उदाहरण स्वतंत्र कार्य हैं जिनका कोई साइड इफेक्ट नहीं है।

कीवर्ड को भी देखें ...


2
यह स्थिर पद्धति कैसे छिपती है और कक्षा का विस्तार करते समय यह अंतर और समस्या कहां से सामने आएगी? इसके साथ सिंक्रनाइज़ कैसे फिट होता है? स्थैतिक और विरासत की समस्याओं का सामना कहाँ करना चाहिए? क्या आप कोर जावा पुस्तकालयों में कुछ अच्छे और बुरे तरीके प्रदान कर सकते हैं और बता सकते हैं कि प्रत्येक मामला क्यों है?
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.