संरक्षित आंतरिक:क्यों सी # संरक्षित और आंतरिक पहुंच के चौराहे का समर्थन नहीं करता है?
संघ की संरक्षित और आंतरिक पहुँच (इस से कम प्रतिबंधक है संरक्षित या आंतरिक अकेले)
CLR अवधारणा है छेदसंरक्षित और आंतरिक पहुंच योग्यता, लेकिन C# इसका समर्थन नहीं करता है।
तो मेरे सवाल है:
इस पहुँच संशोधक को छोड़ते हुए का अर्थ क्या है, वहाँ एक ठोस कारण क्या है? तो क्यों सी # इसका समर्थन नहीं करना चाहिए?
अद्यतन: सी # 7.2 इसे एक्सेस संशोधक private protected के साथ पेश कर रहा है, जो कुछ तरीकों से गलत लगता है लेकिन नीचे वर्णित भ्रम की संभावना से अधिक से बचता है, तो शायद यह एक खराब गुच्छा का सबसे अच्छा है।
व्यक्तिगत रूप से, मैं इसे कुछ बार चाहता था। ऐसे समय होते हैं जब कोई एक वर्ग और एक या अधिक वर्गों को public से एक असेंबली में उजागर करता है, और ऐसे समय होते हैं जब बेस क्लास के कुछ सदस्य केवल उन व्युत्पन्न वर्गों द्वारा उपयोग किए जाते हैं और अन्य में संरक्षित वर्गों के संपर्क में नहीं आते असेंबली (अक्सर कन्स्ट्रक्टर, ताकि अन्य असेंबली को कक्षाओं से प्राप्त करने से रोकने के लिए)।
निश्चित रूप से यथासंभव सीमित रूप से आपकी पहुंच को परिभाषित करना हमेशा अच्छा होता है, और इसलिए सुरक्षित और आंतरिक का चौराहे ठीक वांछित है।
इसके बजाय, मुझे सदस्य internal घोषित करके इसे रोकना पड़ा। अब मेरे कोड में बग की संभावना है जो वहां नहीं होती अगर मैं ऐसी भाषा का उपयोग करता हूं जो मुझे उस छेड़छाड़ का उपयोग करने की अनुमति देता है।
हालांकि, नकारात्मक पक्ष पर विचार करें।
जैसा कि है, protected internalprotected और internal के संघ के बारे में कुछ भ्रम है। यह शायद सबसे गलत समझा जा सकता है, इस तरह की साइटों पर सवालों के आधार पर।
हमें इसे क्या कहना चाहिए? internal protected? क्या आप कल्पना कर सकते हैं कि protected internal के साथ लोग कितनी बार भ्रमित हो जाएंगे? हम कुछ और स्पष्ट रूप से विभेदित करना चाहते हैं, और हम इसे internal protected के लिए चाहते हैं (क्योंकि हमने अभी भी भ्रम के लिए अपनी क्षमता में वृद्धि की है)। जवाब देने में यह असंभव समस्या नहीं है, लेकिन कीवर्ड की संख्या को कम रखना भी एक अच्छा विचार है।
भले ही नामकरण प्रश्न के लिए एक सही उत्तर मिलता है, फिर भी पहुंच का एक और स्तर शुरू करके भ्रम की संभावना पूरी तरह से हार नहीं जाती है।
तो इस बात को ध्यान में रखते हुए, चलो ऊपर की तरफ देखें। internal का उपयोग करके हमें ऐसे समयों को कम करना होगा, इस तरह के सदस्य का उपयोग करके अनुपयुक्त रूप से होने वाली बग को कम करना। ठीक है, यह कितनी बार आता है, और वास्तव में ऐसी बग कितनी संभावना होगी? वास्तव में वास्तव में, और बहुत संभावना नहीं है।
इसलिए संतुलन पर, जबकि मुझे लगता है कि मैं खुद को मौसमी रूप से सी # की इच्छा करता हूं, एक पल की रोकथाम आम तौर पर मुझे खुश करती है कि उन्होंने नहीं किया।
आप उन्हें बिटवाई झंडे के रूप में उपयोग कर सकते हैं, जैसे कुछ: 'संरक्षित और निजी' -> 'निजी '; संरक्षित | आंतरिक '->' सुरक्षित आंतरिक '->' संरक्षित और आंतरिक '-> वांछित परिणाम। –
protected और internal के चौराहे कोड अपने पुस्तकालय के लिए बाहरी के लिए एक सरल internal में डाउनग्रेड कर होगा - जिसका अर्थ यह सुलभ नहीं होगा, व्युत्पन्न वर्ग से या अन्यथा।
इस प्रकार, केवल protected internal intersection का एकमात्र लाभ आपकी लाइब्रेरी के डेवलपर के रूप में स्वयं को अनुशासन के लिए, आपके पुस्तकालय के समान या व्युत्पन्न कक्षाओं को छोड़कर प्रकार/सदस्य तक पहुंचने के लिए नहीं है। यह आपकी लाइब्रेरी के उपभोक्ताओं के लिए कोई फर्क नहीं पड़ेगा, क्योंकि इसके अर्थशास्त्र एक सादे internal के समान होंगे।
उस ने कहा, मुझे सी # में अनुमति देने के लिए इसे अनुचित नहीं पाया गया होगा। आत्म-अनुशासन अक्सर उपयोगी होता है; यही कारण है कि बाहरी डिजाइनरों के समान होने के बावजूद भाषा डिजाइनर private और internal के बीच अंतर करते हैं।
हालांकि, चूंकि चौराहे और सादे internal के बीच भेद छोटा है, इसलिए संभवतः वे इसे अधिक उपयोगी protected internal यूनियन के साथ भ्रमित करने वाले डेवलपर्स के जोखिम को कम करने के लिए इसे बाहर करने का विकल्प चुनते हैं।
सं। संरक्षित 'का मतलब व्युत्पन्न वर्गों से भी सुलभ है, यहां तक कि अन्य पुस्तकालयों में भी; 'आंतरिक' का अर्थ है कि यह अन्य पुस्तकालयों के लिए सुलभ नहीं होगा। – Douglas
यह सी # में भी है। मैंने कहा कि _intersection_ (यदि यह अस्तित्व में था) बाहरी कोड के लिए 'आंतरिक' (या, इसके लिए, एक 'निजी') में डाउनग्रेड होगा। 'संरक्षित आंतरिक' संघ बाहरी कोड के लिए 'संरक्षित' के बराबर है। – Douglas
-1, यह पूरा जवाब यह मान रहा है कि कक्षा पुस्तकालय में एक डेवलपर है और कक्षा पुस्तकालय छोटा है। ऐसा कोई मामला नहीं है जब कई लोग एक साथ बुनियादी ढांचे पर काम करते हैं। उस स्थिति में, चौराहे और सादे 'आंतरिक' के बीच भेद काफी बड़ा है। – tsemer
यह एक डिजाइन निर्णय था, लेकिन पर विचार इसका क्या मतलब:
यह एक बहुत उपयोगी सीमा नहीं है, मैं स्पष्ट उपयोग-मामले के बारे में नहीं सोच सकता।
और यही कारण है कि यह शायद एक नए कीवर्ड (-कंपिनेशन) के साथ आने लायक नहीं था।
मैं पूछूंगा कि सीएलआर इसका समर्थन क्यों करता है। मुझे लगता है कि रूढ़िवादीता।
फिर सवाल यह है कि सीएलआर इसका समर्थन क्यों करता है? –
+1 मैं आपसे सहमत हूं। मैं इसका कोई वास्तविक दुनिया उपयोग नहीं देख सकता। @SoMoS सीएलआर बहुत सी चीजों का समर्थन करता है जो सी # नहीं करता है। –
@ सोमोस: बिल्कुल। लेकिन यह उन सुविधाओं का समर्थन करता है जो इसे सी # में नहीं बनाते हैं, विकल्पों को बनाना होता है। –
तो सी # को इसका समर्थन क्यों नहीं करना चाहिए?
गलत सवाल। सवाल होना चाहिए "क्यों सी # समर्थन protected and internal होना चाहिए?"
ध्यान रखें, एक सुविधा की प्राकृतिक अवस्था में यह के लिए नहीं लागू किया जाये। एक सुविधा को लागू करने संसाधन, परीक्षण के मामले में बहुत महंगा है, और, चलो भूल नहीं, अवसर लागत (जिसका अर्थ है यह विस्थापित के लिए है अन्य फीचर्स)। इसलिए इस खर्च को दूर करने के लिए, इन लागतों को खत्म करने वाली सुविधा को लागू करने के लिए बेहद स्पष्ट लाभ होना बेहतर था।
विशेष रूप से, protected and internal का मूल्य क्या है? पहुंच के लिए वास्तव में कोई अच्छा कारण नहीं है केवल एक ही असेंबली में व्युत्पन्न कक्षाओं के लिए।
आईएमओ यह सीडीआर इसका समर्थन करता है, लेकिन यह अजीब है, लेकिन ऐसा होता है। इसका मतलब यह नहीं है कि सी # को यद्यपि जरूरत है।
जहाँ तक मुझे पता के रूप में आप की रक्षा की और उन्हें आंतरिक पहुंच संशोधक के चौराहे उपयोग कर सकते हैं लेकिन व्याख्या आप (की शायद, क्योंकि जो हेंक कहा) चाहते हैं के साथ नहीं:
संरक्षित: प्रकार या सदस्य ही कर सकते हैं उसी वर्ग या संरचना में, या व्युत्पन्न कक्षा में कोड द्वारा पहुंचा जा सकता है।
आंतरिक: प्रकार या सदस्य को एक ही असेंबली में किसी भी कोड द्वारा एक्सेस किया जा सकता है, लेकिन किसी अन्य असेंबली से नहीं।
संरक्षित आंतरिक: प्रकार या सदस्य को उसी असेंबली में किसी भी कोड द्वारा या किसी अन्य असेंबली में किसी व्युत्पन्न वर्ग द्वारा एक्सेस किया जा सकता है।
प्वाइंट 3) संरक्षित और आंतरिक संघ है, इस सवाल में इसका उल्लेख है। –
प्वाइंट 3) * एक चौराहे नहीं है, यह एक संघ है। यह विपरीत है (एक तरह से)। –
तुम हमेशा कर सकते हैं:
public MyExternallySealedClass
{
internal MyExternallySealedClass() {...}
...
}
जब तक आप न दें के रूप में किसी भी बाहरी उपभोक्ता वस्तु क्या आप चाहेंगे का दृष्टांत अगर वे इसे पाने की कोशिश? संक्षिप्त उत्तर, आपके द्वारा अनुरोधित सुविधा कुछ नया नहीं लाती है और आपके पास पहले से ही टूल्स हैं जो आप अनुरोध कर रहे हैं।
बेशक आपके सरल उदाहरण में एक कामकाज है। हालांकि, किसी वर्ग के बारे में क्या है जिसे अन्य पुस्तकालयों में उप-वर्गीकृत किया जाना चाहिए, लेकिन जिसमें एक ऐसे सदस्य को शामिल करना है जो केवल उन उप-वर्गों के लिए दृश्यमान होना चाहिए जो इसकी मूल असेंबली में परिभाषित हैं? –
@ ओ.आर.मैपरर मैं इसे 'आंतरिक' के रूप में कार्यान्वित करता हूं, इसे व्यापक रूप से दस्तावेज करता हूं, और कोड समीक्षा पर सुनिश्चित करता हूं कि केवल व्युत्पन्न कक्षाएं विधि से अधिक हो रही हैं। यदि इसका 'आंतरिक' आपके पास नियंत्रण है कि चीजों को कैसे कार्यान्वित किया जाता है। यह सही समाधान नहीं है लेकिन यह विशेष मामला भाषा के साथ सुलभ है और मुझे अनुरोधित सुविधा को लागू करने के लिए पर्याप्त कारण नहीं मिला है जो तालिका में थोड़ा और लाएगा। आप मूल रूप से अपनी टीम में कोडिंग शुद्धता को लागू करने के लिए एक भाषा सुविधा का उपयोग कर रहे हैं ... जो मूल रूप से गलत लगता है। – InBetween
मेरी राय में, दोनों धारणाएं कि "यदि इसका आंतरिक आप पर नियंत्रण है कि चीजें कैसे लागू की जाती हैं।" और सार्वजनिक एपीआई (जो बाहरी लोग पहुंचेंगे) की तुलना में आंतरिक एपीआई (केवल आप स्वयं को एक्सेस करते हैं) को रखने के स्पष्ट इरादे (कम से कम आप पहचान सकते हैं) बहुत खराब अभ्यास हैं, लेकिन मैं सहमत हूं कि सी # दुर्भाग्य से करता है इसे बेहतर करने के साधन प्रदान नहीं करते हैं। –
मैं यह वही सवाल पूछना चाहता था, लेकिन शुक्र है कि यह मेरे लिए यह पाया।
मैं इस बात को समझ सकता हूं कि कम से कम एक नया कीवर्ड या मौजूदा कीवर्ड के लिए नए अर्थशास्त्र की आवश्यकता होगी, इसलिए यह समर्थित नहीं था क्योंकि लागत-लाभ इसके पक्ष में काम नहीं करता था।
हालांकि, मैं सवाल करता हूं कि संकीर्ण उपयोग-मामले के कारण इस सीएलआर सुविधा को लागू करने से बचने के लिए वैध है या क्योंकि यह लोगों को भ्रमित कर सकता है।
ऊपर दिया गया एक तर्क यह है कि इसका उपयोग केवल आत्म-अनुशासन को लागू करना होगा।
लेकिन फिर भी किसी भी दृश्यता संशोधक के बारे में कहा जा सकता है जो public नहीं है। विचार यह भी है कि यह केवल 'एक पुस्तकालय के एक एकल डेवलपर' पर लागू होगा, यह भी स्पष्ट रूप से गलत है। कई पुस्तकालय लोगों की टीमों द्वारा विकसित किए जाते हैं, और यह उस टीम के भीतर एक डेवलपर के लिए पूरी तरह से प्राकृतिक है जो सदस्य को जोड़ने के लिए है कि वह केवल अपने आधार से प्राप्त आंतरिक प्रकारों तक सीमित होना चाहता है।
तो फिर वहाँ इस परिदृश्य है:
internal class Foo {
}
public class PublicBase {
protected Foo MyFoo { get; set; }
}
मामले यहाँ में, मैं एक आंतरिक प्रकार है कि मैं एक वर्ग पर बेनकाब करने के लिए करना चाहते हैं, लेकिन मैं केवल व्युत्पन्न प्रकार के लिए इसे उजागर करना चाहते हैं। चूंकि प्रकार आंतरिक है, इसलिए इसका अर्थ है कि एक ही असेंबली में व्युत्पन्न प्रकार। बाहरी प्रकार अभी भी वैध रूप से इस प्रकार से प्राप्त कर सकते हैं, लेकिन उन्हें इस सदस्य का उपयोग करने की आवश्यकता नहीं होगी।
इस स्थिति में मैं अटक गया हूं: मैं protected का उपयोग नहीं कर सकता, और न ही मैं protected internal का उपयोग कर सकता हूं।
इसके बजाय, मुझे internal का उपयोग करना होगा, जो मेरी टीम के अन्य सदस्यों को गलत तरीके से प्रसारित करता है कि इसे कक्षा के बाहर कोड से उपयोग किया जाना चाहिए। निश्चित रूप से मैं इस पर एक टिप्पणी कर सकता हूं (और EditorBrowsableAttributeNever पर भी चिपका सकता हूं, लेकिन यह आंतरिक विरासतकर्ताओं से भी छिपाएगा) - लेकिन यह वही नहीं है।
जैसा कि है, मैं इसे प्राप्त करने का एकमात्र तरीका निर्माण के बाद आईएल पुनर्लेखन के साथ असेंबली को हैक करना चाहता हूं - लेकिन मुझे संकलन के समय इस दृश्यता (या इसकी कमी) की आवश्यकता है, इसके निर्माण के बाद नहीं।
अंत में, के बारे में तर्क "क्या खोजशब्द (ओं) यह प्रयोग करेंगे" या "यह कैसे लागू किया जाएगा" मेरे लिए अप्रासंगिक हैं: मैं प्रोग्रामर, नहीं सी # भाषा डिजाइनर हूँ।
समान रूप से, मुझे जैसे तर्क कहना है "ठीक है, protected internal कई लोगों के लिए पर्याप्त भ्रमित है" भी अप्रासंगिक हैं। ऐसे कई डेवलपर्स हैं जिनके साथ मैं संपर्क में आया हूं, या तो व्यक्तिगत रूप से या वर्चुअल रूप से, जो ?: या सामान्य बाधाओं जैसी चीज़ों को नहीं समझते हैं - अनुमान लगाएं, वे उनका उपयोग नहीं करते हैं! इसका मतलब यह नहीं है कि मुझे नहीं करना चाहिए।
तो हाँ, मैं इसे लागू करने के कारणों को समझता हूं - लेकिन मैं उनसे असहमत हूं - इसलिए मेरा जवाब यह है कि सी # इसका समर्थन क्यों नहीं करता क्योंकि सी # डिजाइनरों को यह गलत लगता है।
और हाँ मैं गर्मी है कि मेरे दरवाजे पर लाने सकता है :)
इसके बाद से यह मौजूदा लोगों के साथ व्यक्त नहीं किया जा सकता किसी दूसरे कीवर्ड की आवश्यकता है के लिए तैयार हूँ। किसी भी भाषा सुविधा में 1000 अंक खर्च होते हैं, एक कीवर्ड की लागत दस लाख अंक होती है। बहुत खड़ी। वीबी.नेट बीटीडब्ल्यू में वही। –
@minitech 'संरक्षित मित्र' सी # की 'संरक्षित आंतरिक' के समान है। यह आपको सीएलआर में मौजूद संरक्षित और आंतरिक पहुंच निर्दिष्ट करने की अनुमति नहीं देता है। –
महान प्रश्न :) – BlackBear