एक भी गतिविधि में साथ फर्क पड़ता है, जब घटकों को परिभाषित ही नहीं गतिविधि के भीतर इस्तेमाल किया जाएगा, निम्नलिखित परिभाषा के बीच वास्तविक अंतर क्या है "हुड के तहत" सम्मेलनों के बारे में सोचा जाना चाहिए (कचरा सफाई, स्मृति, इत्यादि) जो हमेशा सार्वजनिक रूप से निजी तौर पर उपयोग करने का सुझाव देते हैं, अगर इकाई केवल उस वर्ग के अंदर ही उपयोग की जा रही है, जिसमें लिखा गया है?सार्वजनिक या निजी, यह वास्तव में एंड्रॉयड चर
निजी क्षेत्रों encapsulation
यह private उपयोग करने के लिए जब तक आप अन्य वर्गों के लिए एक क्षेत्र या विधि का पर्दाफाश करने की जरूरत है एक आम तौर पर स्वीकार सम्मेलन है को बढ़ावा देने के। इस आदत के रूप में इसे प्राप्त करने से आपको लंबे समय तक बहुत दर्द होता है।
हालांकि, public फ़ील्ड या विधि के साथ स्वाभाविक रूप से कुछ भी गलत नहीं है। यह कचरा संग्रह के लिए कोई फर्क नहीं पड़ता है।
कुछ मामलों में कुछ प्रकार की पहुंच प्रदर्शन को प्रभावित करेगी, लेकिन वे शायद इस प्रश्न के विषय से थोड़ा अधिक उन्नत हैं।
ऐसा एक मामला बाहरी वर्ग क्षेत्रों तक पहुंचने वाले आंतरिक वर्गों के साथ करना है।
class MyOuterClass
{
private String h = "hello";
// because no access modifier is specified here
// the default level of "package" is used
String w = "world";
class MyInnerClass
{
MyInnerClass()
{
// this works and is legal but the compiler creates a hidden method,
// those $access200() methods you sometimes see in a stack trace
System.out.println(h);
// this needs no extra method to access the parent class "w" field
// because "w" is accessible from any class in the package
// this results in cleaner code and improved performance
// but opens the "w" field up to accidental modification
System.out.println(w);
}
}
}
मैं उन छिपी विधियों के बारे में कभी नहीं जानता था इसलिए मैं –
यदि आपकी परिवर्तनीय घोषणा गतिविधि के दायरे के अंदर है, तो यह आमतौर पर स्कॉप्ड वैरिएबल के रूप में सामान्य रूप से कार्य करता है।
हालांकि, यह एक विधि से वैरिएबल का उपयोग करने के लिए खराब प्रोग्रामिंग अभ्यास है जब वे पैरामीटर नहीं हैं।
उदाहरण:
बुरा:
void Foo()
{
int foo = 5;
System.out.println(Bar());
}
int Bar()
{
return foo + 5;
}
यह वास्तव में एक सिंटैक्स त्रुटि फेंक होगा क्योंकि foo के लिए Bar()
अच्छा दायरे से बाहर घोषित किया जाता है:
int foo;
void Foo()
{
foo = 5;
System.out.println(Bar(foo)); //prints 10
}
int Bar(int foo)
{
return foo + 5;
}
क्यों 'अच्छा' अच्छा है हालांकि? –
@ एलेक्स क्योंकि आप अनावश्यक दुष्प्रभावों से बचने के लिए (एक डिजाइन सिद्धांत के रूप में) से बचना चाहते हैं। एक दुष्प्रभाव को कुछ ऐसा माना जाता है जो आपके वर्तमान संदर्भ के बाहर की जानकारी को प्रभावित करता है। – Codeman
आपका 'खराब' संकलित नहीं करता है इसलिए यह बुरा नहीं है, बल्कि यह अस्तित्व में नहीं है। इसलिए अच्छा कुछ भी तुलना नहीं किया जाता है इसलिए मुझे आश्चर्य है कि यह अच्छा क्यों है। –
private और public जावा के दोनों कीवर्ड हैं जिनके पास ऑब्जेक्ट ओरिएंटेड डिज़ाइन का उद्देश्य है। मेरा सुझाव है कि आप इस बारे में पढ़ लें: http://docs.oracle.com/javase/tutorial/java/concepts/
यदि आप केवल अपनी गतिविधि में उन चर (ऑब्जेक्ट्स) का उपयोग करने जा रहे हैं, तो मैं सुझाव दूंगा कि आप उन चर को निजी बनाएं।
मुझे उम्मीद है कि इससे मदद मिलती है।
संपादित करें:
मुझे यकीन है कि अगर, निजी सार्वजनिक या कोई कीवर्ड का उपयोग कर आप परिप्रेक्ष्य के एक स्मृति बिंदु से एप्लिकेशन को अनुकूलित करेंगे नहीं हूँ। जहां तक मैं कह सकता हूं कि मुझे लगता है कि यह नहीं है और आपको इसका उपयोग करना चाहिए जो आपके कोड को सबसे अधिक पढ़ने योग्य, सहज और रखरखाव योग्य बनाता है।
धन्यवाद, मुझे पता है कि वे क्या करते हैं, और मुझे पता है कि उन्हें मेरे मामले में जघन्य होने की आवश्यकता नहीं है, लेकिन मैं सोच रहा था कि क्या कोई भी प्रकार का वूडू मेमोरी मैनेजमेंट या कचरा संग्रह है जो कुछ डिफ़ॉल्ट है या नहीं, सार्वजनिक या निजी। – Octoth0rpe
दृश्यता के दायरे कचरा कलेक्टर या स्मृति प्रबंधन
आप जितना संभव हो उतना दृश्यता का दायरा कम करने के लिए तो अपने कोड बनाए रखने के लिए आसान हो सकता है चाहता हूँ के साथ कोई संबंध नहीं है।
ऊपर उठता हूं धन्यवाद आदमी, कुछ और के आसपास खोदना और ऐसा लगता है कि यह सम्मेलन है: कचरा संग्रह या स्मृति प्रबंधन में कोई अंतर नहीं। निजी यह है। – Octoth0rpe
अच्छी तरह से, एक महत्वपूर्ण बात यह है कि निजी रूप से परिभाषित वैरिएबल जावा प्रोग्रामिंग में मानक है। इसलिए ऑब्जेक्ट्स पर सीधे चर कॉल करना कम से कम उन लोगों के लिए अजीब दिखाई देगा जो संभवतः आपके कोड को पढ़ सकते हैं।
एक और बात जो मैं कहूंगा वह यह है कि यदि आप एक परियोजना पर अकेले कोडिंग नहीं कर रहे हैं तो उन अन्य विशेषताओं के आसपास अजीब काम से बचने के लिए कक्षा कार्यान्वयन पर महत्वपूर्ण विशेषताओं की दृश्यता को सीमित करने के लिए हमेशा एक अच्छा अभ्यास है। साथ आएं।
मैं व्यक्तिगत रूप से नहीं जानता कि उन संशोधकों का उपयोग संकलन और अनुकूलन उद्देश्य के लिए किया जाता है या नहीं।
निष्कर्ष निकालने के लिए जैसा कि मुझे लगता है कि प्रत्येक अनुभवी जावा कोडर मैं गुणों की परिभाषा में इस पैटर्न का उपयोग करने के लिए दृढ़ता से प्रयास करता हूं।
अधिकांश भाग के लिए, विशेष रूप से परिदृश्य में आप वर्णन करते हैं कि सब कुछ सिर्फ एक वर्ग/गतिविधि में है, यह आपके द्वारा उपयोग किए जाने वाले किसी भी चर के दायरे को सीमित करने के लिए अच्छा रूप माना जाता है। –