कक्षा के क्षेत्रों के लिए "संरक्षित" और "सार्वजनिक" दृश्यता बेकार हैं?

protected और public फ़ील्ड के बजाय private फ़ील्ड एक्सेसर्स (गेटर्स और सेटर्स) के साथ के लिए सर्वोत्तम अभ्यास माना जाता है।कक्षा के क्षेत्रों के लिए "संरक्षित" और "सार्वजनिक" दृश्यता बेकार हैं?

तो, इस सर्वोत्तम अभ्यास का पालन करके, हम कभी भी protected और public का उपयोग नहीं करते हैं। क्या वे बेकार हो गए हैं, अन्यथा उनके उपयोग के मामले क्या हैं?

एकमात्र चीज जिसे मैं सोच सकता हूं सार्वजनिक static final विशेषताओं (यानी कक्षा स्थिरांक) के लिए है।

नोट: यह जावा दुनिया में कम से कम दृढ़ता से मामला है, लेकिन सवाल सभी भाषाओं के लिए है।

स्रोत

2012-03-28 Matthieu Napoli

मैं अपने परिसर के साथ सहमत नहीं हैं। 'संरक्षित' दृश्यता के माध्यम से सदस्य चर को उप-वर्ग में बेनकाब करने के वैध कारण हैं। – Richard

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

@Matthieu संक्षेप में, संरक्षित क्षेत्र का उपयोग हमेशा संरक्षित गेटर/सेटर + निजी क्षेत्र द्वारा प्रतिस्थापित किया जा सकता है। – assylias

सर्वोत्तम अभ्यास समय के साथ बदल सकते हैं।
मैं किसी भी तरह विवादास्पद दोनों सार्वजनिक क्षेत्रों के लिए दो उपयोग मामलों में सोच सकता हूं।
एडम बिएन कहते हैं in this post कि यदि आप डीटीओ का उपयोग कर रहे हैं, तो आप निजी + गेटर + सेटर का उपयोग नहीं कर सकते हैं बल्कि केवल सार्वजनिक क्षेत्र का उपयोग नहीं कर सकते हैं। इस तरह आप सुनिश्चित हैं कि बिना किसी बदलाव के डेटा को ट्रांसपोर्ट किया गया है। लेकिन उसी पंक्ति में वह कहते हैं कि इससे आपको बहुत सारी बैठकें मिलती हैं, यह बताते हुए कि आप इसे क्यों करते हैं ...

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

public Person{ 
    public final String lastName; 
    public final String firstName; 
    public Person(String firstName, String lastName){ 
     this.firstName = firstName; 
     this.lastName = lastName; 
    } 
}

अपनी कक्षाओं बनाना एक नया सबसे अच्छा अभ्यास, codemonkeyism जैसी जगहों में सलाह दी किसी प्रकार का है।

लेकिन जब तक आप कोड का पूर्ण स्वामी बन गई हैं और/या आप नए मानकों को पूरा करने के लिए मजबूर कर सकते हैं, तो आप सार्वजनिक/संरक्षित क्षेत्रों के उपयोग से परहेज रखना चाहिए ...

स्रोत

2012-03-28 17:12:32

डीटीओ के बारे में बहुत दिलचस्प दृष्टिकोण। डीटीओ कक्षाएं अक्सर देखने के लिए सिर्फ भयानक हैं। –

कोडेमोनिज्म लिंक टूटा हुआ है – Andy

आंतरिक क्षेत्रों के मामले में? हां, वे कई मामलों में बेकार हैं। (कभी-कभी protected स्वीकार्य है यदि आप उप-वर्ग होने की उम्मीद करते हैं, हालांकि।) और public static final विशेषताएँ भी पूरी तरह से ठीक हैं।

उस ने कहा, public और protectedविधियों बिल्कुल जरूरी हैं।

स्रोत

2012-03-28 15:20:20

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

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

स्रोत

2012-03-28 15:23:56 manub

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

स्रोत

2012-03-28 15:29:27

"बेकार" दर्शक की नजर में है। कुछ "सर्वोत्तम प्रथाओं" अतिरेखित हैं:

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

मान लीजिए कि आप किसी ऐसे मान तक पहुंच चाहते हैं जो कभी भी परिवर्तित न हो (जैसे सरणी की लंबाई) public final फ़ील्ड इसके लिए सही है। साथ ही, "कॉन्स्टेंट्स" कक्षा होना बेहद आम है जिसमें public static final फ़ील्ड के अलावा कुछ भी नहीं है। public static final फ़ील्ड के साथ अनगिनत मानक लाइब्रेरी कक्षाएं हैं। दरअसल, लगभग हर बार जब आप सार्वजनिक स्थिरता चाहते हैं तो यह उपयोग करने की बात है।

protected फ़ील्ड बहुत दुर्लभ हैं, AFAIK। आपको वास्तव में दूरदर्शिता और protected का उपयोग करने की आवश्यकता के लिए उप-वर्ग रखने की योजना बनाने की आवश्यकता है।

स्रोत

2012-03-28 15:29:38 trutheality

"हर बार जब आप सार्वजनिक स्थिरता चाहते हैं तो यह उपयोग करने की बात है" => निरंतर क्या है, इस पर निर्भर करता है कि एक enum बेहतर विकल्प हो सकता है। – assylias

अच्छा बिंदु। असल में मानक पुस्तकालयों में 'सार्वजनिक स्थिर अंतिम' के उपयोग का एक गुच्छा है जो कि अगर वे enums थे तो अच्छी तरह से देखा होगा। – trutheality

सार्वजनिक, निजी, संरक्षित और पैकेज फ़ील्ड तक ही सीमित नहीं हैं।

विधियों और रचनाकारों पर उपयोग करने के लिए बहुत उपयोगी अनुप्रयोग हैं।

हालांकि, यह केवल निजी क्षेत्र के लिए फ़ील्ड को सीमित करने की कोशिश करने के लिए असंगत होगा क्योंकि जावा नेस्टेड/आंतरिक कक्षाओं के मामले में ऐसा करने में सक्षम नहीं है।

स्रोत

2012-03-28 15:33:47

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

स्रोत

2012-03-28 15:38:31 kasavbere

कक्षा के क्षेत्रों के लिए "संरक्षित" और "सार्वजनिक" दृश्यता बेकार हैं?

उत्तर

संबंधित मुद्दे