स्थिर चर को बुराई क्यों माना जाता है?

Question

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

मैं स्थिर चर का उपयोग करने के लिए और अधिक सुविधाजनक है। और मुझे लगता है कि वे भी कुशल हैं (कृपया मुझे गलत होने पर सही करें), क्योंकि अगर मुझे एक कक्षा के भीतर एक समारोह में 10,000 कॉल करने पड़ते हैं, तो मुझे खुशी होगी कि मैं इस पद्धति को स्थिर बनाऊं और Class.methodCall()इसके बजाय इसका सीधा उपयोग करूं कक्षा के 10,000 उदाहरणों के साथ मेमोरी को अव्यवस्थित करना, सही?

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

पुनश्च: कृपया मुझे सही करें अगर मेरी स्टैटिक्स के बारे में धारणा गलत है।

Comments

केवल कहने के लिए, स्मॉलटाकल या स्काला पर कोई स्थिर वैरिएबल या विधियाँ नहीं हैं, बिल्कुल वैसा ही क्योंकि स्टैटिक विधियाँ और चर OOP सिद्धांतों के विरुद्ध हैं।

— मॉरीशो लिन्हार्स

आपके द्वारा किए गए कम से कम एक बयान बल्कि जिज्ञासु है: "स्टेटिक्स कोड के अन्य भागों पर अंतर-निर्भरता को कम करता है"। सामान्य तौर पर वे निर्भरता को कसते हैं। जिस कोड पर कॉल किया जाता है उसे कोड कहा जाता है। बीच में कोई अमूर्तता नहीं, प्रत्यक्ष निर्भरता।

— Arne Deutsch

अच्छा सवाल ... एक Programmers.SE के अधिक प्रश्न थ?

— वर्नरसीडी

आपका दूसरा पैराग्राफ एक पूरी तरह से अलग विषय के बारे में है, अर्थात् स्थिर तरीके ।

— पॉल

फ़ंक्शनल प्रोग्रामिंग भी वैश्विक राज्य पर निर्भर करता है। यदि आप कभी भी (और आपको चाहिए ) एक दिन में एफपी हो जाते हैं, तो वैश्विक स्थिति की धारणा को खोदने के लिए तैयार रहें।

— new123456

Answer 1

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

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

Comments

यह हाल ही में एक तर्क लगता है, चाहे कोड परीक्षण योग्य हो या नहीं। यह एक बल्कि त्रुटिपूर्ण तर्क है। तर्क 'अच्छा डिज़ाइन' होना चाहिए, और आमतौर पर अच्छा डिज़ाइन परीक्षण योग्य होता है। लेकिन नहीं अन्य तरीके के आसपास: "मैं यह परीक्षण नहीं कर सकता कि यह खराब डिजाइन होना चाहिए।" हालांकि मुझे गलत मत समझो, मैं आपकी पोस्ट से सामान्य रूप से सहमत हूं।

— M प्लैटवेट

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

— जॉन स्कीट

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

— जस्टिन मॉर्गन

@ एम प्लैटवेट - टेस्टिबिलिटी भी पुन: प्रयोज्यता को प्रभावित करती है, क्योंकि एक डिकॉप्ड क्लास का आमतौर पर पुन: उपयोग करना आसान होता है।

— TrueWill

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

— दाऊद इब्न करीम

Answer 2

इसकी बहुत वस्तु उन्मुख नहीं है: कुछ लोगों द्वारा एक कारण स्टैटिक्स को "बुराई" माना जा सकता है क्योंकि वे वस्तु-उन्मुख प्रतिमान के विपरीत हैं । विशेष रूप से, यह उस सिद्धांत का उल्लंघन करता है कि डेटा ऑब्जेक्ट्स में एनकैप्सुलेटेड है (जिसे बढ़ाया जा सकता है, जानकारी छिपाना, आदि)। स्टैटिक्स, जिस तरह से आप उनका उपयोग करने का वर्णन कर रहे हैं, अनिवार्य रूप से उन्हें गुंजाइश के रूप में मुद्दों से निपटने से बचने के लिए एक वैश्विक चर के रूप में उपयोग करना है। हालांकि, वैश्विक चर प्रक्रियात्मक या अनिवार्य प्रोग्रामिंग प्रतिमान की परिभाषित विशेषताओं में से एक है, न कि "अच्छा" वस्तु उन्मुख कोड की विशेषता। यह कहना नहीं है कि प्रक्रियात्मक प्रतिमान खराब है, लेकिन मुझे यह आभास होता है कि आपका पर्यवेक्षक आपसे "अच्छी वस्तु उन्मुख कोड" लिखने की अपेक्षा करता है और आप वास्तव में लिखना चाहते हैं "

जावा में कई गोटेकास होते हैं जब आप स्टैटिक्स का उपयोग करना शुरू करते हैं जो हमेशा तुरंत स्पष्ट नहीं होते हैं। उदाहरण के लिए, यदि आपके पास एक ही वीएम में चल रहे आपके प्रोग्राम की दो प्रतियां हैं, तो क्या वे स्टेटिक वैरिएबल वैल्यू और मेस को एक-दूसरे की स्थिति से दूर कर देंगे? या जब आप वर्ग का विस्तार करते हैं तो क्या होता है, क्या आप स्थैतिक सदस्य को ओवरराइड कर सकते हैं? क्या आपका VM मेमोरी से बाहर चल रहा है क्योंकि आपके पास स्टैटिक्स की पागल संख्याएँ हैं और उस मेमोरी को अन्य आवश्यक इंस्टेंस ऑब्जेक्ट्स के लिए पुनः प्राप्त नहीं किया जा सकता है?

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

कुछ पुन: उपयोग को रोकता है: इसके अलावा, एक इंटरफ़ेस को लागू करने के लिए स्थिर तरीकों का उपयोग नहीं किया जा सकता है, इसलिए स्थिर तरीके कुछ ऑब्जेक्ट ओरिएंटेड सुविधाओं को प्रयोग करने योग्य होने से रोक सकते हैं।

अन्य विकल्प: यदि कार्यकुशलता आपकी प्राथमिक चिंता है, तो गति समस्या को हल करने के लिए अन्य बेहतर तरीके हो सकते हैं, केवल यह विचार करने की तुलना में कि आह्वान का लाभ आमतौर पर सृजन की तुलना में अधिक तेज़ होता है। विचार करें कि कहीं क्षणिक या वाष्पशील संशोधक की आवश्यकता है या नहीं। इनबिल्ट होने की क्षमता को संरक्षित करने के लिए, एक विधि को स्थैतिक के बजाय अंतिम रूप में चिह्नित किया जा सकता है। विधि पैरामीटर और अन्य चर को कुछ संकलक अनुकूलन की अनुमति देने के लिए अंतिम रूप से चिह्नित किया जा सकता है जो उन चर को बदल सकते हैं। एक इंस्टेंस ऑब्जेक्ट को हर बार एक नया इंस्टेंस बनाने के बजाय कई बार पुन: उपयोग किया जा सकता है। सामान्य रूप से एप्लिकेशन के लिए चालू किया जाना चाहिए जो कि कंपाइलर ऑप्टिमाइज़ेशन स्विच हो सकते हैं। शायद, डिजाइन स्थापित किया जाना चाहिए ताकि 10,000 रन बहु-थ्रेडेड हो सकें और मल्टी-प्रोसेसर कोर का लाभ उठा सकें। यदि पोर्टबेलिटी isn '

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

Comments

मुझे आपका जवाब पसंद है, मुझे लगता है कि यह सही ट्रेडऑफ पर ध्यान केंद्रित करने पर ध्यान केंद्रित करता है, जैसे कि समरूपता और कार्यक्षेत्र जैसे कुछ लाल झुंडों के बजाय। और सिंगल के लिए +1, एक बेहतर सवाल वास्तव में हो सकता है कि स्टेटिक वैरिएबल / मेथड्स को

— सिंगलेट्स

भले ही सिंगलटन थ्रेड-सुरक्षित हो सकता है (उदाहरणों का उपयोग करके synchronized), इसका मतलब यह नहीं है कि कॉलिंग कोड सिंगलटन स्टेट के संबंध में दौड़ की स्थिति से मुक्त है।

— एंड्रे कैरन

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

— एंड्रे कैरन

यदि मैं गलत नहीं हूँ, तो तीसरे पैराग्राफ की अंतिम पंक्ति को आपके सभी गैर-स्थिर चर को पढ़ना चाहिए ।

— स्टीव

Object Lifetime, एक बहुत ही महत्वपूर्ण बिंदु है जिसका @jessica ने उल्लेख किया है।

— अभिधम्म

Answer 3

बुराई एक व्यक्तिपरक शब्द है।

आप निर्माण और विनाश के संदर्भ में स्टैटिक्स को नियंत्रित नहीं करते हैं। वे कार्यक्रम लोडिंग और अनलोडिंग के इशारे पर रहते हैं।

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

ये दो मुख्य मुद्दे हैं जो मैंने उनके साथ रखे हैं।

Answer 4

नहीं, वैश्विक राज्य प्रति सेवारत नहीं हैं। लेकिन हमें आपका कोड यह देखना होगा कि क्या आपने इसे ठीक से इस्तेमाल किया है। यह काफी संभव है कि एक नौसिखिया वैश्विक राज्यों का दुरुपयोग करता है; ठीक उसी तरह जैसे वह हर भाषा फीचर का दुरुपयोग करता है।

वैश्विक राज्यों की पूर्ण आवश्यकता है। हम वैश्विक राज्यों से बच नहीं सकते। हम वैश्विक राज्यों के बारे में तर्क करने से बच सकते हैं। - अगर हम अपने आवेदन शब्दार्थ को समझने की परवाह करते हैं।

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

वसंत लोगों की तरह जो भव्य रूप से xml में वैश्विक राज्यों की घोषणा करते हैं और सोचते हैं कि यह किसी भी तरह बेहतर है।

@ जोंन स्कीट if I create a new instance of an objectअब आपके पास तर्क करने के लिए दो चीजें हैं - वस्तु के भीतर की स्थिति, और वस्तु की मेजबानी करने वाले पर्यावरण की स्थिति।

Comments

"मेरे पास दो चीजें हैं जिनके बारे में तर्क करना है"। नहीं अगर मैं अपना परीक्षण केवल वस्तु स्थिति पर निर्भर करता हूं। जो आसान है, मेरे पास कम वैश्विक स्थिति है।

— डीजेकेवर्थ

निर्भरता इंजेक्शन का वैश्विक राज्य या वैश्विक दृश्यता से कोई लेना-देना नहीं है- यहाँ तक कि कंटेनर भी वैश्विक नहीं है। "सामान्य" कोड की तुलना में, केवल एक कंटेनर द्वारा प्रबंधित कंटेनर के लिए दिखाई देने वाली एकमात्र अतिरिक्त चीज़ है। वास्तव में, सिंग्लटन पैटर्न से बचने के लिए DI का उपयोग आमतौर पर किया जाता है।

— 21

Answer 5

स्थैतिक चर के साथ 2 मुख्य समस्याएं हैं:

• थ्रेड सेफ्टी - स्टैटिक रिसोर्स परिभाषा के अनुसार हैं थ्रेड-सेफ नहीं
• कोड इम्प्लेसी

Comments

मुझे लगता है कि जॉन स्कीट उसी टिप्पणी का उल्लेख कर रहे थे जो आपने पोस्ट की थी।

— आरजी -3

मुझे थ्रेड सेफ्टी पॉइंट नहीं मिलता है, मुझे लगता है कि जब तक आप ऐसा नहीं करते तब तक कुछ भी सुरक्षित नहीं है। यह स्थिर चीजों से संबंधित नहीं लगता है, कृपया मुझे सही करें अगर मुझे कुछ याद आ रहा है।

— Zmaster

@ ज़मास्टर - हालांकि यह सच है कि थ्रेड-सेफ्टी स्टैटिक वेरिएबल्स के लिए विशेष रूप से एक मुद्दा नहीं है, क्योंकि उनकी परिभाषा से उन्हें अलग-अलग संदर्भों से बुलाया जाना है, वे उन्हें अधिक पसंद करते हैं

— स्टर्नर

@sternr मुझे समझ में आया कि आपका क्या मतलब है, अगर "अलग-अलग संदर्भ" "अलग-अलग सूत्र" के बराबर नहीं हैं। लेकिन यह सच है कि थ्रेड-सेफ्टी को अक्सर स्थैतिक संसाधनों के साथ ध्यान में रखना पड़ता है। आपको सजा को स्पष्ट करने पर विचार करना चाहिए।

— जेडएमआर

उदाहरण के लिए, स्थैतिक संसाधनों के वैध थ्रेड सुरक्षित उपयोग हैं। निजी स्थिर अंतिम लकड़हारा लॉग = लकड़हारा.लोगलॉगर (Foo.class); निजी स्टैटिक फाइनल एटोमिकइंटर x = न्यू एटोमिकइंटर (0); जैसा कि मैं इसे समझता हूं, इस तरह के संसाधनों के स्थिर असाइनमेंट को क्लास लोडर द्वारा थ्रेड-सुरक्षित की गारंटी दी जाती है। लकड़हारा उदाहरण स्वतंत्र रूप से थ्रेड-सेफ़ नहीं है जहाँ आप इसे पॉइंटर असाइन करते हैं। स्टेटिक्स को स्टैटिक्स में रखना शायद एक अच्छा विचार नहीं है, लेकिन कोई कारण नहीं है कि यह थ्रेड-सुरक्षित नहीं होना चाहिए।

— टेकनोपुल

Answer 6

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

मैं अनुमान लगाता हूं कि जब मैं, फाइनल ’के बिना the स्टैटिक’ देखता हूं, तो यह लगभग 85% होता है, यह गलत है। अक्सर, मैं इन समस्याओं को मास्क करने या छिपाने के लिए अजीबोगरीब वर्कआउट करूंगा।

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

स्टैटिक्स का उपयोग करने से बहुत सूक्ष्म कीड़े पैदा हो सकते हैं जो दर्द के इंजीनियरों दिनों को बनाए रखेंगे। मुझे पता है, क्योंकि मैंने इन दोनों कीड़ों को बनाया और उनका शिकार किया है।

यदि आप अधिक जानकारी चाहते हैं, तो कृपया पढ़ें ...

क्यों नहीं स्टैटिक्स का उपयोग करें?

स्टैटिक्स के साथ कई मुद्दे हैं, जिसमें लेखन और निष्पादन परीक्षण, साथ ही सूक्ष्म कीड़े शामिल हैं जो तुरंत स्पष्ट नहीं हैं।

स्थिर वस्तुओं पर निर्भर कोड आसानी से परीक्षण की गई इकाई नहीं हो सकता है, और स्टैटिक्स को आसानी से (आमतौर पर) मज़ाक नहीं किया जा सकता है।

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

और डेटाबेस की आबादी और आरंभीकरण में लंबा समय लगता है। और मेरे अनुभव में, आपका डीबी इनिशियलाइज़ेशन फ्रेमवर्क समय के साथ बदल जाएगा, जिसका अर्थ है कि डेटा मॉर्फ होगा, और परीक्षण टूट सकते हैं। IE, कल्पना करें कि ग्राहक 1 एक वीआईपी हुआ करता था, लेकिन DB आरंभीकरण ढांचा बदल गया, और अब ग्राहक 1 अब VIP नहीं है, लेकिन आपका परीक्षण ग्राहक 1 को लोड करने के लिए कठिन-कोडित किया गया था ...

एक बेहतर तरीका यह है कि एक CustomerDAO को तत्काल भेजा जाए, और जब इसका निर्माण हो जाए, तो इसे CustomerFilter में पास कर दें। (स्प्रिंग का उपयोग करने के लिए एक बेहतर तरीका यह होगा कि कंट्रोल फ्रेमवर्क का दूसरा उलटा उपयोग किया जाए।

एक बार जब आप ऐसा कर लेते हैं, तो आप अपने CustomerFilterTest में एक वैकल्पिक DAO को जल्दी से मॉक या स्टब कर सकते हैं, जिससे आपको परीक्षण पर अधिक नियंत्रण रखने की अनुमति मिलती है,

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

परीक्षाएँ छूटती हैं

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

यह एक सामान्यीकृत उदाहरण है, लेकिन बड़ी प्रणालियों में, यह समस्या ALL TIME होती है। लोग एक ही JVM में अपने सॉफ़्टवेयर को बार-बार शुरू करने और रोकने के लिए इकाई परीक्षणों के बारे में नहीं सोचते हैं, लेकिन यह आपके सॉफ़्टवेयर डिज़ाइन का एक अच्छा परीक्षण है, और यदि आपके पास उच्च उपलब्धता के लिए आकांक्षाएं हैं, तो यह कुछ ऐसा है जिसके बारे में आपको जानकारी होनी चाहिए।

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

यदि सिस्टम कॉन्फ़िगरेशन जो इन फ्रेमवर्क घटकों पर लागू होता है, यूनिट परीक्षणों के बीच बदल जाता है, और यूनिट टेस्ट फ्रेमवर्क फाड़ नहीं देता है और घटकों का पुनर्निर्माण नहीं करता है, तो ये परिवर्तन प्रभावी नहीं हो सकते हैं, और जब कोई परीक्षण उन परिवर्तनों पर निर्भर करता है, तो वे विफल हो जाएंगे। ।

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

इससे भी बदतर, विफलता उस क्रम पर आधारित हो सकती है जिसमें परीक्षण चलाए गए थे।

इस मामले में, स्टैटिक्स से बचकर, आप परीक्षण उदाहरणों में डेटा को बनाए रखने के जोखिम से बचते हैं, बेहतर परीक्षण विश्वसनीयता सुनिश्चित करते हैं।

सूक्ष्म कीड़े

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

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

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

एक पहलू: स्टेटिक फाइनल

"स्टैटिक फ़ाइनल" का उपयोग प्रभावी रूप से C #define के जावा समतुल्य है, हालाँकि तकनीकी कार्यान्वयन अंतर हैं। संकलन से पहले AC / C ++ #define को प्री-प्रोसेसर द्वारा कोड से स्वैप किया जाता है। एक जावा "स्टैटिक फाइनल" स्टैक पर मेमोरी रेजिडेंट को समाप्त कर देगा। इस तरह, यह C # में "स्थिर कॉन्स्टेबल" वैरिएबल से अधिक है, जितना कि यह #define पर है।

सारांश

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

Answer 7

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

स्टेटिक्स कोड के अन्य भागों पर अंतर-निर्भरता को कम करता है। वे पूर्ण राज्य धारक के रूप में कार्य कर सकते हैं

मुझे आशा है कि आप ताले का उपयोग करने और विवाद से निपटने के लिए तैयार हैं।

* दरअसल, प्रीत संघ ने इसका उल्लेख किया है।

Comments

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

— स्टूजेक

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

— जस्टिन एम। कीज़

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

— सुपरकैट

Answer 8

जावा में स्थैतिक तरीकों का उपयोग करने के कुछ बुनियादी फायदे और नुकसान:

लाभ:

1. वैश्विक रूप से सुलभ यानी किसी विशेष वस्तु उदाहरण के साथ बंधे नहीं।
2. जेवीएम प्रति एक उदाहरण।
3. वर्ग नाम (कोई वस्तु की आवश्यकता) का उपयोग करके पहुँचा जा सकता है।
4. सभी उदाहरणों पर लागू एक एकल मान रखता है।
5. JVM स्टार्टअप पर लोड करें और JVM बंद होने पर मर जाता है।
6. वे वस्तु की स्थिति को संशोधित नहीं करते हैं।

नुकसान:

1. स्थैतिक सदस्य हमेशा स्मृति का हिस्सा होते हैं चाहे वे उपयोग में हों या नहीं।
2. आप स्थैतिक चर के निर्माण और विनाश को नियंत्रित नहीं कर सकते। उपयोगी रूप से वे प्रोग्राम लोडिंग पर नष्ट कर दिए गए हैं और जब प्रोग्राम अनलोड (या जब जेवीएम बंद हो जाता है) तबाह हो जाता है।
3. आप सिंक्रोनाइज़ का उपयोग करके स्टैटिक्स के धागे को सुरक्षित बना सकते हैं लेकिन आपको कुछ अतिरिक्त प्रयासों की आवश्यकता है।
4. यदि एक थ्रेड स्थैतिक चर का मान बदलता है जो संभवतः अन्य थ्रेड्स की कार्यक्षमता को तोड़ सकता है।
5. इसका उपयोग करने से पहले आपको "स्थिर" पता होना चाहिए।
6. आप स्थैतिक तरीकों को ओवरराइड नहीं कर सकते।
7. सीरियलाइजेशन उनके साथ अच्छा काम नहीं करता है।
8. वे रनटाइम बहुरूपता में भाग नहीं लेते हैं।
9. यदि कोई बड़ी संख्या में स्थिर चर / विधियों का उपयोग किया जाता है, तो एक स्मृति समस्या है (कुछ हद तक लेकिन मुझे नहीं लगता है)। क्योंकि वे कार्यक्रम समाप्त होने तक कचरा एकत्र नहीं होंगे।
10. स्थैतिक तरीकों का भी परीक्षण करना कठिन है।

Comments

नुकसान 6, 7, 8 और 10 उपयोग की गई भाषाओं / रूपरेखाओं के नुकसान हैं, और सामान्य रूप से स्थिर चर के नुकसान नहीं हैं। नुकसान 1, 4 और 5 अन्य समाधानों के लिए भी मौजूद हैं, जैसे कुछ रूपरेखा द्वारा प्रदान किए गए कुछ सिंगलटन पैटर्न। (मैंने जवाब देने के लिए वोट नहीं दिया, क्योंकि मैं बाकी लोगों से सहमत हूं और यह एक अच्छा संग्रह है।)

— पीटर -

Answer 9

अगर मुझे एक कक्षा के भीतर किसी फ़ंक्शन के लिए 10,000 कॉल करने पड़ते हैं, तो मुझे खुशी होगी कि विधि को स्थिर बनाने और उस पर कक्षा के 10,000 उदाहरणों के साथ मेमोरी को अव्यवस्थित करने के बजाय उस पर एक सीधा वर्ग.methodCall () का उपयोग करें, है ना?

आपको किसी राज्य के साथ किसी ऑब्जेक्ट में डेटा को इनकैप्सुलेट करने की आवश्यकता को संतुलित करना होगा, कुछ डेटा पर फ़ंक्शन के परिणाम की गणना करने की आवश्यकता है।

इसके अलावा स्टैटिक्स कोड के अन्य भागों पर अंतर-निर्भरता को कम करते हैं।

तो एनकैप्सुलेशन करता है। बड़े अनुप्रयोगों में, स्टेटिक्स स्पेगेटी कोड का उत्पादन करते हैं और आसानी से रिफैक्टिंग या परीक्षण की अनुमति नहीं देते हैं।

अन्य उत्तर भी स्टेटिक्स के अत्यधिक उपयोग के खिलाफ अच्छे कारण प्रदान करते हैं।

Answer 10

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

कहा जा रहा है, नियमित स्थैतिक चर (आमतौर पर बुरा माना जाता है), और अंतिम स्थैतिक चर (AKA स्थिरांक; इतना बुरा नहीं) के बीच अंतर करना महत्वपूर्ण है।

Comments

"स्टेटिक चर कक्षाओं में राज्य का प्रतिनिधित्व करते हैं" ... मुझे लगता है कि आपका मतलब है "स्थिर चर उदाहरणों में राज्य का प्रतिनिधित्व करते हैं"? +1 "अंतिम स्थिर AKA स्थिरांक के लिए, इतना बुरा नहीं"। चूंकि मान बदल नहीं सकता है, जो कुछ भी उस समय एक बिंदु पर निर्भर करता है वह बाद के समय में अपने व्यवहार को बदल नहीं सकता है - मान समान है।

— जारेड अपडेटाइक

"स्टेटिक वेरिएबल्स उदाहरणों में राज्य का प्रतिनिधित्व करते हैं" इसे बताते हुए एक बेहतर तरीका है। मैंने अपना उत्तर संपादित कर दिया है।

— जैक एडमंड्स

Answer 11

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

यह केवल तर्क को अलग करने और इसे एक अच्छी जगह देने के बारे में है। कभी-कभी यह स्थिर तरीकों के उपयोग को सही ठहराता है, जो java.lang.Mathएक अच्छा उदाहरण है। मुझे लगता है कि जब आप अपनी अधिकांश कक्षाओं का नाम लेते हैं XxxUtilया Xxxhelperआप अपने डिजाइन पर बेहतर पुनर्विचार करते हैं।

Comments

शुद्ध साइड इफेक्ट फ्री स्टेटिक तरीके पूरी तरह से ठीक हैं। लेकिन वैश्विक उत्परिवर्ती राज्य शायद ही कभी होता है और मैं ओपी की व्याख्या वैश्विक राज्य के बारे में कर रहा हूं।

— कोडइन्चोस 16

@CodeInChaos पूरी तरह से सहमत हैं। मुझे पता है कि ओपी स्थिर तरीकों और var के बीच के अंतर पर पूरी तरह से स्पष्ट नहीं है।

— एम प्लैटवेट

Answer 12

मैंने उत्तरों में किए गए कुछ बिंदुओं को संक्षेप में प्रस्तुत किया है। यदि आपको कुछ भी गलत लगता है तो कृपया इसे ठीक करने के लिए स्वतंत्र महसूस करें।

स्केलिंग: हमारे पास JVM प्रति स्थिर वैरिएबल का ठीक एक उदाहरण है। मान लीजिए कि हम एक पुस्तकालय प्रबंधन प्रणाली विकसित कर रहे हैं और हमने किताब का नाम एक स्थिर चर रखने का फैसला किया है क्योंकि प्रति पुस्तक केवल एक ही है। लेकिन अगर सिस्टम बढ़ता है और हम कई जेवीएम का उपयोग कर रहे हैं, तो हमारे पास यह पता लगाने का कोई तरीका नहीं है कि हम किस किताब के साथ काम कर रहे हैं?

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

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

राज्य के बारे में तर्क: यदि मैं एक वर्ग का नया उदाहरण बनाता हूं तो हम इस उदाहरण की स्थिति के बारे में तर्क कर सकते हैं लेकिन यदि इसमें स्थिर चर हैं तो यह किसी भी राज्य में हो सकता है। क्यों? क्योंकि यह संभव है कि स्थिर चर को कुछ भिन्न उदाहरणों द्वारा संशोधित किया गया है क्योंकि स्थिर चर को उदाहरणों में साझा किया गया है।

क्रमबद्धता: सीरियलाइजेशन भी उनके साथ अच्छा काम नहीं करता है।

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

लेकिन क्या होगा अगर हमें वास्तव में उनकी आवश्यकता है?

लेकिन कभी-कभी हमें उनकी वास्तविक ज़रूरत हो सकती है। अगर हम वास्तव में कई स्टैटिक वैरिएबल्स की जरूरत महसूस करते हैं जो एप्लिकेशन में साझा किए जाते हैं तो एक विकल्प सिंगलटन डिजाइन पैटर्न का उपयोग करना है जिसमें ये सभी वैरिएबल होंगे। या हम कुछ ऑब्जेक्ट बना सकते हैं जिसमें ये स्टैटिक वेरिएबल होंगे और इन्हें पास किया जा सकता है।

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

Answer 13

मुझे लगता है कि आप स्थैतिक चर के बारे में पूछ रहे हैं, लेकिन आप अपने उदाहरणों में स्थैतिक तरीकों को भी इंगित करते हैं।

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

स्थैतिक विधियाँ उर्फ ​​उपयोगिता विधि। यह आमतौर पर उनका उपयोग करने के लिए एक बुरा अभ्यास नहीं है, लेकिन प्रमुख चिंता यह है कि वे बाधा डाल सकते हैं परीक्षण में ।

महान जावा परियोजना के एक उदाहरण के रूप में जो बहुत सारे स्टैटिक्स का उपयोग करता है और इसे सही तरीके से करता है कृपया प्ले को देखें! ढांचा । एसओ में इसे लेकर भी चर्चा है ।

स्थैतिक आयात के साथ संयुक्त स्थैतिक चर / तरीके भी व्यापक रूप से पुस्तकालयों में उपयोग किए जाते हैं जो जावा में घोषित प्रोग्रामिंग की सुविधा प्रदान करते हैं जैसे: इसे आसान बनाना या Hamcrest । यह बहुत सारे स्थिर चर और तरीकों के बिना संभव नहीं होगा।

इसलिए स्थैतिक चर (और विधियाँ) अच्छे हैं, लेकिन उन्हें बुद्धिमानी से उपयोग करें!

Answer 14

स्थैतिक चर सबसे महत्वपूर्ण रूप से डेटा की सुरक्षा (किसी भी समय बदल गया, किसी को भी बदल सकते हैं, वस्तु के बिना प्रत्यक्ष पहुंच, आदि) के साथ समस्या पैदा करते हैं।

अधिक जानकारी के लिए इस धन्यवाद को पढ़ें ।

Answer 15

यह सुझाव दिया जा सकता है कि ज्यादातर मामलों में जहां आप एक स्थिर चर का उपयोग करते हैं, आप वास्तव में सिंगलटन पैटर्न का उपयोग करना चाहते हैं ।

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

Answer 16

फिर भी एक और कारण: नाजुकता।

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

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

यदि आप स्थैतिक चर का उपयोग कर रहे हैं, तो यह टूट जाएगा। कीड़े महंगे हैं।

संभावित रूप से क्लूलेस डेवलपर्स द्वारा एक -0001% प्रदर्शन में सुधार और मजबूती के बीच, बहुत सारे मामलों में मजबूती ही अच्छा विकल्प है।

Answer 17

मैं स्थिर चर का उपयोग करने के लिए और अधिक सुविधाजनक है। और मुझे लगता है कि वे भी कुशल हैं (कृपया मुझे सही करें अगर मैं गलत हूं तो) क्योंकि अगर मुझे एक कक्षा के भीतर एक समारोह में 10,000 कॉल करने पड़ते हैं, तो मुझे खुशी होगी कि मैं विधि को स्थिर बनाऊं और एक सीधी कक्षा का उपयोग करूं। कक्षा के 10,000 उदाहरणों के साथ स्मृति को अव्यवस्थित करने के बजाय, सही पर?

मैं देखता हूं कि आप क्या सोचते हैं, लेकिन एक साधारण सिंगलटन पैटर्न 10 000 ऑब्जेक्ट्स को इंस्टेंट किए बिना ऐसा ही करेगा।

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

उदाहरण के लिए:

public class WaterContainer {
    private int size;
    private int brand;
    ...etc

    public static int convertToGallon(int liters)...

    public static int convertToLiters(int gallon)...

}

Comments

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

— कोडइन्चोस 16

मुझे यकीन नहीं है कि मैं आपकी टिप्पणी को समझूंगा! मैं ओपी को जवाब दे रहा था कि उसने 10 000 वस्तुओं को भड़काने के बारे में इटैलिक में क्या कहा था। मुझे समझ में नहीं आता कि आप एक एकल और एक स्थिर चर की तुलना क्यों करते हैं? मैंने जो कुछ भी लिखा उससे आपको समझ में आता है कि सिंगलटन खराब डिजाइन है ...! मुझे लगता है कि मैं आपको गलत

— समझता

एक क्लासिक सिंगलटन (जिसमें है Class.Instance) जो कि उत्परिवर्तनीय स्थिति को वहन करता है, खराब डिजाइन आईएमओ है। उस मामले में मैं दृढ़ता से एक डिजाइन पसंद करता हूं, जहां मुझे एकल गाने मिलते हैं जो मुझे कक्षा में पैरामीटर के रूप में उपयोग करने की आवश्यकता होती है जो उनका उपयोग करता है (आमतौर पर डीआई की मदद से)। तार्किक रूप से अपरिवर्तनीय क्लासिक सिंगलटन आईएमओ ठीक हैं।

— कोडइन्चोस

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

— एडविन बक

Answer 18

'स्टेटिक्स के बुरे होने' का मुद्दा वैश्विक राज्य के बारे में अधिक है। किसी वैरिएबल के स्थिर होने का उपयुक्त समय, यदि यह कभी एक से अधिक अवस्था में न हो; IE उपकरण जो पूरे ढांचे द्वारा सुलभ होने चाहिए और हमेशा उसी पद्धति के कॉल के लिए समान परिणाम लौटाते हैं, वे कभी स्टेटिक्स के रूप में 'बुराई' नहीं होते हैं। आपकी टिप्पणी के अनुसार:

मैं स्थिर चर का उपयोग करने के लिए और अधिक सुविधाजनक है। और मैं मानता हूं कि वे कुशल भी हैं

स्टेटिक्स वैरिएबल / क्लासेस के लिए आदर्श और कुशल विकल्प हैं जो कभी नहीं बदलते हैं ।

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

अच्छे कोड में प्रतिबंध की वैश्विक स्थिति के कुछ अपवाद हैं, जैसे कि घड़ी। समय वैश्विक है, और - कुछ अर्थों में - यह कोडित संबंध के बिना वस्तुओं की स्थिति को बदलता है।

Comments

"समय वैश्विक है" - कंप्यूटिंग सिस्टम में समय को मॉडल करने के अन्य तरीके हैं जैसे कि यह कुछ अंतर्निहित, वैश्विक चीज है जो अपने आप बदल जाती है। सीएफ यह सर्वेक्षण: "कम्प्यूटिंग में मॉडलिंग का समय: एक वर्गीकरण और एक तुलनात्मक सर्वेक्षण" @ arxiv.org/abs/0807.4132

— Jared Updike

Answer 19

मेरा $ .02 यह है कि इनमें से कई उत्तर समस्या को भ्रमित कर रहे हैं, बल्कि यह कहना कि "स्टेटिक्स खराब हैं" मुझे लगता है कि स्कूपिंग और उदाहरणों के बारे में बात करना बेहतर है।

मैं क्या कहूंगा कि एक स्थिर "वर्ग" चर है - यह उस मूल्य को पुन: प्रदर्शित करता है जो उस वर्ग के सभी उदाहरणों में साझा किया जाता है। आमतौर पर इसे उस तरह से स्कूप किया जाना चाहिए जैसे (संरक्षित या निजी से लेकर कक्षा और उसके उदाहरण)।

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

मुझे लगता है कि क्यों मुझे लगता है कि अन्य उत्तरों में कुछ पहलू सवाल के लिए महत्वपूर्ण नहीं हैं ...

स्टैटिक्स "ग्लोबल" नहीं हैं। जावा में स्कोपिंग को स्थैतिक / उदाहरण से अलग से नियंत्रित किया जाता है।

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

जीवन चक्र का प्रबंधन एक दिलचस्प तर्क है, लेकिन मुझे लगता है कि यह कम महत्वपूर्ण है। मैं यह नहीं देखता कि एकल वर्ग उदाहरण के निर्माण और विनाश की तुलना में init () / clear () जैसे क्लास तरीकों की एक जोड़ी को प्रबंधित करने के लिए इसकी कोई भी कड़ी क्यों है। वास्तव में, कुछ लोग कह सकते हैं कि एक सिंगलटन जीसी के कारण थोड़ा अधिक जटिल है।

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

Answer 20

आपकी पोस्ट में दो मुख्य प्रश्न हैं।

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

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

निष्कर्ष में: स्थैतिक चर के उपयोग से बचें और स्थैतिक या गैर स्थैतिक तरीकों से निपटने पर सही प्रदर्शन संतुलन खोजें।

पुनश्च: मेरी अंग्रेजी के लिए क्षमा करें।

Answer 21

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

Answer 22

a) कार्यक्रमों के बारे में कारण।

यदि आपके पास एक छोटा- midsize- प्रोग्राम है, जहां स्थिर वैरिएबल Global.foo एक्सेस किया गया है, तो इसके लिए कॉल सामान्य रूप से कहीं से आता है - कोई रास्ता नहीं है, और इसलिए कोई समयरेखा नहीं है, चर कैसे जगह पर आता है, जहां यह प्रयोग किया जाता है। अब मुझे कैसे पता चलेगा कि किसने इसे इसके वास्तविक मूल्य पर सेट किया है? मुझे कैसे पता चलेगा, क्या होता है, अगर मैं इसे अभी संशोधित करता हूं? मेरे पास पूरे स्रोत पर grep है, सभी एक्सेस इकट्ठा करने के लिए, यह जानने के लिए कि क्या चल रहा है।

यदि आप जानते हैं कि आप इसका उपयोग कैसे करते हैं, क्योंकि आपने अभी कोड लिखा है, समस्या अदृश्य है, लेकिन यदि आप विदेशी कोड को समझने की कोशिश करते हैं, तो आप समझ पाएंगे।

बी) क्या आपको वास्तव में केवल एक की आवश्यकता है?

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

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

Answer 23

सब कुछ (:) का उद्देश्य हो सकता है, अगर आपके पास थ्रेड्स का गुच्छा है जो डेटा / कैश डेटा को साझा करने की आवश्यकता है और सभी सुलभ मेमोरी (इसलिए आप एक जेवीएम के भीतर संदर्भों में विभाजित नहीं होते हैं) स्थैतिक सबसे अच्छा विकल्प है

-> बेशक आप मजबूर कर सकते हैं सिर्फ एक उदाहरण, लेकिन क्यों?
मुझे इस सूत्र में कुछ टिप्पणियाँ बुरी लगती हैं, स्टैटिक्स नहीं;)

Answer 24

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

जब आप संबंधित संबंधित मानों को रखने के लिए स्थिर चर का उपयोग करने का प्रयास करते हैं तो समस्याएँ सामने आती हैं।

Answer 25

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

Comments

लेकिन क्या आपके कोड को कुछ मानक मानक प्रतिमान का पालन करने के लिए सख्ती से विचार करने से वास्तव में कोड बेहतर हो जाता है, या क्या हम काम करने वाले कोड को लिखने से बचने के लिए शिकायत कर रहे हैं?

— ज़ोइ

हां यह इसे बेहतर बनाता है, क्योंकि यह भविष्य में इसे अधिक प्रबंधनीय बनाता है, समझने में अधिक आसान और अधिक स्पष्ट।

— ब्लॉकहैड

OO कोड नहीं लिखना क्यों बुराई है? और क्यों Bjarne Stroustrup आपके साथ सहमत नहीं है? सिर्फ एक नाम के लिए ...

— को Lorne

मैंने यह नहीं कहा कि इसकी बुराई OO कोड नहीं लिखती। मैंने कहा कि यह सोचने के लिए कि आप OO कोड लिख रहे हैं, जब आप सभी स्थैतिक तरीकों और गुणों के पीछे ग्लोबल्स को नंगा कर रहे हैं। कृपया जो मैंने लिखा है उसे फिर से पढ़ें।

— ब्लॉकहेड

Answer 26

यहाँ पर बहुत सारे अच्छे उत्तर हैं,

मेमोरी: स्टेटिक वैरिएबल तब तक जीवित रहते हैं जब तक क्लास लोडर रहता है [सामान्य रूप से वीएम तक मर जाता है], लेकिन यह केवल थोक वस्तुओं / संदर्भों में स्थिर के रूप में संग्रहीत होता है।

संशोधन: IOC, dependencyInjection, प्रॉक्सी आदि जैसी अवधारणाओं पर विचार करें। सभी पूरी तरह से कसकर युग्मन / स्थैतिक कार्यान्वयन के खिलाफ हैं।

अन्य कॉन: थ्रेड सेफ्टी, टेस्टिबिलिटी

Answer 27

सोचें कि यदि आपके पास कई उपयोगकर्ताओं के साथ एक एप्लिकेशन है और आपने स्थैतिक रूप को परिभाषित किया है, तो प्रत्येक उपयोगकर्ता अन्य उपयोगकर्ताओं के सभी अन्य रूपों को भी संशोधित करेगा।

Answer 28

मुझे लगता है कि स्थैतिक कीवर्ड के साथ वैश्विक चर के अत्यधिक उपयोग से भी एप्लिकेशन में कुछ बिंदु पर मेमोरी रिसाव हो सकता है

Answer 29

मेरे दृष्टिकोण से staticचर को केवल कन्वेंशन द्वारा बनाए गए डेटा या चर को पढ़ना चाहिए ।

उदाहरण के लिए हमारे पास किसी परियोजना का एक ui है, और हमारे पास देशों, भाषाओं, उपयोगकर्ता भूमिकाओं आदि की एक सूची है और हमारे पास इस डेटा को व्यवस्थित करने के लिए कक्षा है। हमें पूरा यकीन है कि ऐप इस सूचियों के बिना काम नहीं करेगा। इसलिए हम ऐप इनिट पर सबसे पहले अपडेट के लिए इस सूची की जाँच कर रहे हैं और इस सूची को एपीआई (यदि आवश्यक हो) से प्राप्त कर रहे हैं। इसलिए हम सहमत हैं कि यह डेटा "हमेशा" ऐप में मौजूद है। यह व्यावहारिक रूप से केवल डेटा पढ़ा जाता है, इसलिए हमें इसकी देखभाल करने की आवश्यकता नहीं है - इस मामले के बारे में सोचकर हम वास्तव में उन डेटा के बहुत सारे उदाहरण नहीं चाहते हैं - यह मामला स्थिर होने के लिए एक आदर्श उम्मीदवार दिखता है ।

Answer 30

मैंने स्टैटिक्स के साथ बहुत खेला है और क्या मैं आपको थोड़ा अलग जवाब दे सकता हूं - या शायद इसे देखने के लिए थोड़ा अलग तरीका है?

जब मैंने एक कक्षा में स्टैटिक्स का उपयोग किया है (सदस्य और विधियाँ दोनों) मैंने अंततः यह देखना शुरू कर दिया कि मेरी कक्षा वास्तव में जिम्मेदारी साझा करने वाली दो कक्षाएं हैं - "स्टैटिक" भाग है जो एक सिंगलटन की तरह काम करता है और गैर है -स्टेटिक पार्ट (एक सामान्य वर्ग)। जहाँ तक मुझे पता है आप हमेशा उन दो वर्गों को पूरी तरह से अलग कर सकते हैं सिर्फ एक कक्षा के लिए सभी स्टेटिक्स का चयन करके और दूसरे के लिए गैर-स्टैटिक्स।

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

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