बिना कब्ज के कैसे रहें?

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

1. अपरिवर्तनीय वस्तुएँ

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

2. इंटरफ़ेस

एक विकल्प केवल रीड ऑब्जेक्ट के लिए एक इंटरफ़ेस बनाना है जिसमें से ऑब्जेक्ट को संशोधित करने वाले सभी तरीकों को बाहर करना है। और अगर यह ऑब्जेक्ट जेनेरिक है, तो इंटरफ़ेस में कोवरियन को भी जोड़ा जा सकता है। एक वेक्टर के साथ एक उदाहरण के लिए यह इस तरह दिखेगा:

interface IVectorConst<out T> { T this[int nIndex] { get; } } class Vector<T> : IVectorConst<T> { private readonly T[] _vector; public Vector(int nSize) { _vector = new T[nSize]; } public T this[int nIndex] { get { return _vector[nIndex]; } set { _vector[nIndex] = value; } } } void ReadVector(IVectorConst<int> vector) { ... } 

(वैसे, वेक्टर और IVectorConst (या IVectorReader - जैसा कि आप चाहें) के बीच आप एक कंट्राविरेंट IVectorWriter भी जोड़ सकते हैं।)

और सबकुछ ठीक हो जाएगा, लेकिन रीडवेक्टर को वेक्टर के डाउनकास्ट करने और इसे बदलने से कुछ भी नहीं रोक रहा है। हालाँकि, यदि आप C ++ से कास्ट को याद करते हैं, तो यह विधि समान रूप से अविश्वसनीय कॉन्स्टेबल से कम विश्वसनीय नहीं है, जो किसी भी पॉइंटर रूपांतरण पर रोक नहीं लगाती है। यदि यह आपके लिए पर्याप्त है, तो आप रोक सकते हैं, यदि नहीं, तो आगे बढ़ें।

3. "एडेप्टर" के माध्यम से एक स्थिर वस्तु का पृथक्करण

हम उपर्युक्त डाउनकास्ट को केवल एक ही तरीके से प्रतिबंधित कर सकते हैं: सुनिश्चित करें कि वेक्टर IVectorConst से विरासत में नहीं आता है, अर्थात इसे अलग करें। ऐसा करने का एक तरीका एक वेक्टरकॉन्स्ट "एडेप्टर" बनाना है (इस विधि को याद करने के लिए ऑस्मीर्नोव के लिए धन्यवाद, इसके बिना लेख अधूरा होगा)। यह इस तरह दिखेगा:

 interface IVector<in T> { T this[int nIndex] { set; } } interface IVectorConst<out T> { T this[int nIndex] { get; } } class VectorConst<T> : IVectorConst<T> { private readonly Vector<T> _vector; public VectorConst(Vector<T> vector) { _vector = vector; } public T this[int nIndex] { get { return _vector[nIndex]; } } } class Vector<T> : IVector<T> { private readonly T[] _vector; public Vector(int nSize) { _vector = new T[nSize]; } public T this[int nIndex] { get { return _vector[nIndex]; } set { _vector[nIndex] = value; } } public IVectorConst<T> AsConst { get { return new VectorConst<T>(this); } } } 

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

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

4. एक स्थिर वस्तु का वास्तविक पृथक्करण

एक वेक्टर के साथ एक ही उदाहरण में, यह इस तरह दिखेगा:

 interface IVectorConst<out T> { T this[int nIndex] { get; } } interface IVector<in T> { T this[int nIndex] { set; } } struct VectorConst<T> : IVectorConst<T> { private readonly T[] _vector; public VectorConst(T[] vector) { _vector = vector; } public T this[int nIndex] { get { return _vector[nIndex]; } } } struct Vector<T> : IVector<T> { private readonly T[] _vector; private readonly VectorConst<T> _reader; public Vector(int nSize) { _reader = new VectorConst<T>(_vector = new T[nSize]); } public T this[int nIndex] { set { _vector[nIndex] = value; } } public VectorConst<T> Reader { get { return _reader; } } public static implicit operator VectorConst<T>(Vector<T> vector) { return vector._reader; } } 

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

 public static implicit operator VectorConst<T>(Vector<T> vector) { return vector._reader; } 

हालाँकि, सीधे ऑब्जेक्ट का उपयोग करते समय, हम रीडर प्रॉपर्टी को कॉल किए बिना नहीं कर सकते:

 var v = new Vector<int>(5); v[0] = 0; Console.WriteLine(v.Reader[0]); 

और इसके बिना हम ऐसा नहीं कर सकते हैं अगर हमें आईवेक्टरकॉन्स्ट के सहसंयोजक (रूपांतरण की उपस्थिति की उपस्थिति के बावजूद) का उपयोग करने की आवश्यकता है:

 class A { } class B : A { } private static void ReadVector(IVectorConst<A> vector) { ... } var vector = new Vector<B>(); ReadVector(vector.Reader); 

और यह इस दृष्टिकोण का मुख्य और शायद एकमात्र ऋण है: कुछ मामलों में रीडर को कॉल करने की आवश्यकता के कारण इसका उपयोग कुछ असामान्य है। लेकिन जब सी # के पास तर्कों की कमी होती है, तो आपको किसी भी मामले में कुछ त्याग करना होगा।

कई लोग शायद कहेंगे कि ये सभी सामान्य सत्य हैं। लेकिन शायद किसी के लिए यह लेख और ये सरल टेम्पलेट उपयोगी होंगे।