जावा में, यह सिखाया जाता है कि बेहतर encapsulation सक्षम करने के लिए चर को निजी रखा जाना चाहिए, लेकिन स्थिर स्थिरांक के बारे में क्या? यह:'सार्वजनिक स्थैतिक अंतिम' या 'निजी स्थिर अंतिम' गेटटर के साथ?
public static final int FOO = 5;
इस के परिणाम में बराबर होगा:
private static final int FOO = 5;
...
public static getFoo() { return FOO; }
लेकिन जो बेहतर अभ्यास है?
आपके कोड में सीधे स्थिरता का उपयोग न करने का एक कारण है।
मान लें कि खाद्य बाद में बदल सकता है (लेकिन फिर भी स्थिर रहें), public static final int FOO = 10; पर कहें। तब तक कुछ भी तोड़ना नहीं चाहिए जब तक कोई भी बेवकूफ मूल्य को सीधे सही करने के लिए पर्याप्त नहीं है?
नहीं। जावा कंपाइलर कॉलिंग कोड में उपरोक्त फू जैसे इनलाइन स्थिरांक, यानी someFunc(FooClass.FOO);someFunc(5); बन जाएगा। अब अगर आप अपनी लाइब्रेरी को पुनः संकलित करते हैं लेकिन कॉलिंग कोड नहीं है तो आप आश्चर्यजनक परिस्थितियों में समाप्त हो सकते हैं। यदि आप किसी फ़ंक्शन का उपयोग करते हैं तो इससे बचा जाता है - जेआईटी अभी भी इसे ठीक से अनुकूलित करेगा, इसलिए कोई असली प्रदर्शन वहां नहीं मारा गया।
दिलचस्प, मुझे कभी यह एहसास नहीं हुआ। मैं कभी जंगली में गेटर्स के साथ स्थिरांक में नहीं आया हूं। –
जानकारी के लिए धन्यवाद, ऐसा लगता है कि निजी स्थिरांक और गेटर्स अनुभवी रूप से सुरक्षित विकल्प हैं और बेहतर अभ्यास माना जाना चाहिए। –
@ क्रिस आपके आधार पर निर्भर करता है - पत्थर में सेट किए गए बहुत से स्थिरांक हैं (उदाहरण के लिए 'पीआई' इन सभी वर्षों के बाद 3 होने की संभावना नहीं है;) तो मैं सभी मामलों में सार्वजनिक स्थिरांक के उपयोग की निंदा नहीं करेगा। लेकिन इसे किसी को ध्यान में रखना चाहिए, क्योंकि ऐसी समस्या को डीबग करना अत्यंत भयानक है। – Voo
चूंकि आप इसे अंतिम स्थिरता के रूप में उपयोग करने के बाद अंतिम चर को बाद में नहीं बदला जा सकता है, तो इसे सार्वजनिक रूप से कोई भी आवश्यक नहीं है।
केवल अगर आप पूरी तरह से निश्चित हैं तो आप कभी भी अंतिम चर को नहीं बदलेंगे। स्थिरांक को कंपाइलर द्वारा रेखांकित किया जाता है जो बाद में बदलते समय बेहद आश्चर्यजनक परिणाम ले सकता है और आप सबकुछ पुनः संकलित नहीं करते हैं। संपादित करें: चित्रित, यह है – Voo
गेटर यहां व्यर्थ है और सबसे अधिक संभावना JVM द्वारा रेखांकित की जाएगी। बस सार्वजनिक स्थिरता के साथ छड़ी।
encapsulation के पीछे विचार एक चर के अवांछित परिवर्तनों की रक्षा करना और आंतरिक प्रतिनिधित्व को छिपाना है। स्थिरांक के साथ यह ज्यादा समझ में नहीं आता है।
पहला अगर getFoo परिणाम महंगा है और रनटाइम पर मूल्यांकन करने की आवश्यकता नहीं है।
सदस्य पर सेटटर और गेटर का उपयोग करने का लाभ ओवरराइट करने में सक्षम होना है। यह स्थैतिक "विधियों" (बल्कि कार्यों)
इंटरफ़ेस स्थिर तरीकों को परिभाषित करने का कोई तरीका नहीं है।
मैं क्षेत्र का उपयोग
मैं getFoo के साथ रहना चाहते हैं() के बाद से यह आप ग्राहक कोड बदले बिना भविष्य में कार्यान्वयन बदलने की अनुमति देता के साथ जाना होगा। जैसा कि @ टोमाज़ ने नोट किया है, जेवीएम शायद आपके वर्तमान कार्यान्वयन को रेखांकित करेगा, इसलिए आप प्रदर्शन प्रदर्शन का अधिक भुगतान करते हैं।
के रूप में कक्षा के बाहर variales का उपयोग करें:
public def FOO:Integer = 5;
यदि आप कैप्सूलीकरण आपकी प्राथमिकता नहीं है। अन्यथा दूसरे संस्करण का उपयोग करें ताकि आप एक विधि का पर्दाफाश करें और चर नहीं।
private static final int FOO = 5;
...
public static getFoo() { return FOO; }
कोड रखरखाव के लिए भी बेहतर अभ्यास है ताकि वे चर पर भरोसा न करें। याद रखें कि "समयपूर्व अनुकूलन सभी बुराइयों की जड़ है"।
रचनात्मक पर बंद करने के लिए वोटिंग (पहले से प्रस्तावित राय प्रतिक्रिया के आधार पर)। क्या 'फू' वास्तव में स्थिर है? क्या एपीआई का 'फू' हिस्सा प्रदान करने वाला वर्ग है? या एक अंत बिंदु आवेदन का हिस्सा? गणितीय स्थिरांक हैं जो कभी नहीं बदलते हैं। ऐसे छोटे झंडे भी हैं जिन्हें कभी नहीं बदला जाना चाहिए (एसडब्ल्यूटी देखें)। तो जवाब है "यह निर्भर करता है।" –