उत्परिवर्तनीय महत्वपूर्ण प्रकारों के खतरों पर

अधिकांश प्रोग्रामर, जिन्हें मुश्किल भाग्य ने मंच पर लाया है। नेट, मूल्य प्रकार और संदर्भ प्रकारों के अस्तित्व से अवगत हैं। और उनमें से काफी कुछ अच्छी तरह से जानते हैं कि नाम के अलावा, इन प्रकारों में अन्य अंतर हैं, जैसे कि स्मृति में इन प्रकारों की वस्तुओं का स्थान, साथ ही साथ शब्दार्थ भी।

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

हालांकि यह अंतर बहुत महत्वपूर्ण है और यह इसके लिए धन्यवाद है कि महत्वपूर्ण प्रकार मौजूद हैं और उपयोग किए जाते हैं, इस प्रकार के जोड़े में एक और है, कोई कम महत्वपूर्ण महत्वपूर्ण अंतर नहीं है। महत्वपूर्ण प्रकार, जैसा कि नाम से पता चलता है, वे मान हैं जो हर बार कॉपी किए जाने पर या किसी फ़ंक्शन से दिए जाने पर कॉपी किए जाते हैं । और जब से कॉपी करते हैं, तब, जैसा कि, फिर से, नाम से पता चलता है, प्रतिलिपि प्रेषित नहीं होती है और वापस आ जाती है, लेकिन बदलने के सभी प्रयासों से कॉपी में बदलाव होगा, न कि मूल उदाहरण।


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

आइए इन कुछ उदाहरणों को देखें।

1. वस्तु गुण के रूप में एक परस्पर महत्वपूर्ण प्रकार

आइए अपेक्षाकृत सरल उदाहरण से शुरू करें जिसमें नकल काफी स्पष्ट है। मान लें कि हमारे पास कुछ परिवर्तनशील सार्थक प्रकार हैं (जो, वैसे भी, न केवल इसके लिए उपयोगी होंगे, बल्कि बाद के सभी उदाहरणों के लिए) Mutable कहलाते हैं और कुछ वर्ग A जिसमें निर्दिष्ट प्रकार की संपत्ति होती है:

struct Mutable
{
public Mutable( int x, int y)
: this ()
{
X = x;
Y = y;
}
public void IncrementX() { X++; }
public int X { get ; private set ; }
public int Y { get ; set ; }
}
class A
{
public A() { Mutable = new Mutable(x: 5, y: 5); }
public Mutable Mutable { get ; private set ; }
}

* This source code was highlighted with Source Code Highlighter .

अब तक, ऐसा लगता है, कुछ भी दिलचस्प नहीं है, लेकिन आइए निम्न उदाहरण देखें:

A a = new A();
a.Mutable.Y++;

* This source code was highlighted with Source Code Highlighter .

सबसे दिलचस्प बात यह है कि यह कोड बिल्कुल भी संकलित नहीं करता है, क्योंकि दूसरी पंक्ति ( a.utable.Y ++;) C # भाषा के दृष्टिकोण से गलत है। चूँकि एक ही नाम की संपत्ति से लौटने पर म्यूटेबल संरचना के मूल्य की नकल की जाती है, इसलिए संकलन चरण पर पहले से ही संकलक समझता है कि अस्थायी वस्तु को बदलने से अच्छा कुछ नहीं होगा, जो त्रुटि संदेश में स्पष्ट है: " त्रुटि 161612: 'के वापसी मूल्य को संशोधित नहीं कर सकता' System.Collections.Generic.IList <MutableValueTypes.Mutable> .this [int] 'क्योंकि यह एक चर नहीं है "। हर कोई जो C ++ भाषा से अधिक या कम परिचित है, उसके लिए यह व्यवहार काफी समझ में आएगा, क्योंकि कोड की इस पंक्ति में हम एक मान को बदलने से ज्यादा कुछ नहीं करने की कोशिश कर रहे हैं जो कि एल-मूल्य नहीं है।

यद्यपि संकलक ++ संचालक के शब्दार्थ को समझता है, सामान्य रूप से, उसे यह पता नहीं है कि कोई विशेष कार्य वर्तमान वस्तु के साथ क्या करता है, विशेष रूप से, चाहे वह इसे बदलता है या नहीं। और यद्यपि हम पिछले कोड के टुकड़े में वाई संपत्ति के ++ ऑपरेटर को कॉल नहीं कर सकते हैं, हम एक्स संपत्ति के इंक्रीमेंटएक्स विधि को सुरक्षित रूप से कॉल कर सकते हैं:

Console .WriteLine( " Mutable.X: {0}" , a.Mutable.X);
a.Mutable.IncrementX();
Console .WriteLine( "Mutable.X IncrementX(): {0}" , a.Mutable.X);

* This source code was highlighted with Source Code Highlighter .

हालांकि पिछला कोड सही ढंग से व्यवहार नहीं करता है, लेकिन नग्न आंखों के साथ एक त्रुटि को खोलना हमेशा आसान नहीं होता है। हर बार जब Mutable वर्ग की संपत्ति तक पहुंच बनाई जाती है, तो एक नई प्रतिलिपि बनाई जाती है, जिसके लिए IncrementX पद्धति को कॉल किया जाता है, लेकिन चूंकि कॉपी बदलने का मूल ऑब्जेक्ट को बदलने से कोई लेना-देना नहीं है, इसलिए कंसोल पर आउटपुट पिछले डेटा फ़्रेग्मेंट के अनुरूप होगा:

मूल मूल्य Mutable.X: 5

IncrementX (): 5 कॉल करने के बाद Mutable.X

"हम्म ... अलौकिक कुछ भी नहीं," आप कहते हैं, और आप सही होंगे ... जब तक हम अन्य, अधिक दिलचस्प मामलों को नहीं देखेंगे।

2. परस्पर सार्थक प्रकार और आसानी से संशोधक

आइए कक्षा B को देखें , जो हमारे पठनीय क्षेत्र के रूप में हमारी उत्परिवर्तनीय उत्परिवर्ती संरचना है:

class B
{
public readonly Mutable M = new Mutable(x: 5, y: 5);
}

* This source code was highlighted with Source Code Highlighter .

फिर, यह रॉकेट साइंस नहीं है, बल्कि सबसे सरल वर्ग है, जिसका एकमात्र दोष एक खुले क्षेत्र का उपयोग है। लेकिन चूंकि इस क्षेत्र का खुलापन एक सरल उदाहरण और सुविधा के कारण है, न कि त्रुटियों को डिजाइन करने के लिए, आपको इस ट्रिफ़ल पर ध्यान नहीं देना चाहिए। इसके बजाय, आपको इस वर्ग के उपयोग और प्राप्त परिणामों के एक सरल उदाहरण पर ध्यान देना चाहिए।

B b = new B();
Console .WriteLine( " MX: {0}" , bMX);
bMIncrementX();
bMIncrementX();
bMIncrementX();
Console .WriteLine( "MX IncrementX: {0}" , bMX);

* This source code was highlighted with Source Code Highlighter .

तो परिणामस्वरूप आउटपुट क्या होगा? 8? (मुझे आपको याद दिलाना चाहिए कि संपत्ति X का प्रारंभिक मूल्य 5 है, और 5 + 3, जैसा कि ज्ञात है, 8 के बराबर; 7 बेहतर हो सकता है, लेकिन, अफसोस, यह उतना ही निकला जितना 8) या, शायद -8? एक चुटकुला।

ऐसा लगता है कि एम एक ऐसी संपत्ति नहीं है जिसे हर बार इसे वापस करने पर कॉपी किया जाएगा, इसलिए उत्तर 8 काफी तार्किक लगता है। हालांकि, संकलक (और सी # भाषा विनिर्देश, वैसे भी) हमारे साथ असहमत होंगे और इस कोड के निष्पादन के परिणामस्वरूप, एमएक्स अभी भी 5 होगा:

मूल एमएक्स: 5

IncrementX (): 5 पर तीन कॉल के बाद एमएक्स

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

Console .WriteLine( " MX: {0}" , bMX);
Mutable tmp1 = bM;
tmp1.IncrementX();
Mutable tmp2 = bM;
tmp2.IncrementX();
Mutable tmp3 = bM;
tmp3.IncrementX();
Console .WriteLine( "MX IncrementX: {0}" , bMX);

* This source code was highlighted with Source Code Highlighter .

(हां, यदि आप आसानी से संशोधित संशोधक को हटाते हैं, तो आपको अपेक्षित परिणाम मिलेगा; IncrementX विधि के तीन कॉल के बाद, चर M की X संपत्ति का मान होगा 8.)

3. एरे और सूची

अगले, लेकिन स्पष्ट रूप से अंतिम नहीं, परिवर्तनशील महत्वपूर्ण प्रकारों के गैर-स्पष्ट व्यवहार का क्षण सरणियों और सूचियों में उनका उपयोग है। तो, चलो एक संग्रह में एक उत्परिवर्तनीय महत्वपूर्ण प्रकार का एक तत्व रखते हैं, उदाहरण के लिए, सूची <T> सूची में।

List <Mutable> lm = new List <Mutable> { new Mutable(x: 5, y: 5) };

* This source code was highlighted with Source Code Highlighter .

चूंकि सूची सूचकांक एक सामान्य संपत्ति है, इसलिए इसका व्यवहार पहले खंड में वर्णित उस से अलग नहीं होता है: हर बार, सूची आइटम तक पहुंचने पर, हमें स्रोत आइटम नहीं, बल्कि इसकी एक प्रति प्राप्त होगी।

lm[0].Y++; //
lm[0].IncrementX(); //

* This source code was highlighted with Source Code Highlighter .

अब एक ही ऑपरेशन को ऐरे से करने की कोशिश करते हैं:

Mutable[] am = new Mutable[] { new Mutable(x: 5, y: 5) };
Console .WriteLine( " X: {0}, Y: {1}" , am[0].X, am[0].Y);
am[0].Y++;
am[0].IncrementX();
Console .WriteLine( " X: {0}, Y: {1}" , am[0].X, am[0].Y);

* This source code was highlighted with Source Code Highlighter .

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

लेकिन हालांकि C # सामान्य मामले में प्रबंधित लिंक की वापसी का समर्थन नहीं करता है, विशेष IL-code निर्देश के रूप में एक विशेष अनुकूलन है जो आपको किसी सरणी तत्व की न केवल प्रतिलिपि प्राप्त करने की अनुमति देता है, बल्कि इसके लिए एक लिंक (जिज्ञासु के लिए, इस निर्देश को ldelema कहा जाता है)। इस विशेषता के कारण, पिछला टुकड़ा न केवल पूरी तरह से सही है (स्ट्रिंग am [0] .Y ++ सहित;); लेकिन यह आपको सीधे सरणी के तत्वों को बदलने की अनुमति देता है, न कि उनकी प्रतियों को। और यदि आप पिछले कोड के टुकड़े को चलाते हैं, तो आप देखेंगे कि यह संकलन, रन, और सीधे सरणी के शून्य ऑब्जेक्ट को संशोधित करता है।

प्रारंभिक मान X: 5, Y: 5

नए मूल्य X: 6, Y: 6

हालांकि, अगर ऊपर माना गया सरणी इसके इंटरफेस में से किसी एक में कम हो जाता है, जैसे कि IList <T> , तो विशेष IL-निर्देश उत्पन्न करने के रूप में सभी सड़क का जादू छोड़ दिया जाएगा, और हमें इस खंड की शुरुआत में वर्णित व्यवहार मिलेगा।

Mutable[] am = new Mutable[] { new Mutable(x: 5, y: 5) };
IList<Mutable> lst = am;
lst[0].Y++; //
lst[0].IncrementX(); //

* This source code was highlighted with Source Code Highlighter .

4. और मुझे यह सब क्यों चाहिए?

सवाल वाजिब है, खासकर अगर आपको याद है कि आप कितनी बार अपने खुद के सार्थक प्रकारों का निर्माण करते हैं, और इससे भी अधिक कितनी बार आप उन्हें परिवर्तनशील बनाते हैं। लेकिन इस ज्ञान से एक लाभ है। सबसे पहले, हम दुनिया में केवल प्रोग्रामर नहीं हैं, यह अनुमान लगाना मुश्किल नहीं है, कई अन्य "गवरिक्स" हैं जो भयानक बल के साथ कोडित करते हैं और अपनी खुद की परिवर्तनशील संरचनाएं बनाते हैं। और यहां तक ​​कि अगर आपकी टीम में व्यक्तिगत रूप से ऐसे "गैवीक्स" नहीं हैं, तो वे अन्य टीमों में हैं, उदाहरण के लिए, .Net फ्रेमवर्क विकास टीम में। हां, .Net फ्रेमवर्क में पर्याप्त संख्या में उत्परिवर्तनीय महत्वपूर्ण प्रकार मौजूद हैं, जिसके अनजाने उपयोग से महंगा आश्चर्य (**) हो सकता है।

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

var x = new { Items = new List < int > { 1, 2, 3 }.GetEnumerator() };
while (x.Items.MoveNext())
{
Console .WriteLine(x.Items.Current);
}

* This source code was highlighted with Source Code Highlighter .

(इस कोड को LINQPad या मुख्य विधि में कॉपी करें और चलाएं।)

निष्कर्ष

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

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

-----------------------------

(*) एक बंद इतना भयानक जानवर नहीं है क्योंकि यह एक जटिल नाम से प्रतीत हो सकता है। और अगर अचानक, किसी कारण से, आप इस बारे में अपने ज्ञान के बारे में सुनिश्चित नहीं हैं, तो यह इसे ठीक करने के लिए सिर्फ एक महान कारण है: "सी # में क्लोजर" ।

(**) सबसे दिलचस्प बात यह है कि परस्पर सार्थक प्रकार एकमात्र संदिग्ध समाधान से दूर हैं, जिसका प्रकटन आसानी से .Net फ्रेमवर्क में पाया जा सकता है। एक और समान रूप से संदिग्ध डिजाइन निर्णय आभासी घटनाओं का व्यवहार है (जो मैंने पहले के बारे में लिखा था), और उनके सभी अस्पष्ट व्यवहार के लिए, वे भी .Net फ्रेमवर्क में मौजूद हैं (उदाहरण के लिए, ऑब्जर्वेबल कॉलेलेशन क्लास के प्रॉपर्टीचैन्ड और कलेक्चर्ड इवेंट वर्चुअल हैं)

(***) यह एरिक लिपर्ट के लेखों में से एक के लिए एक सूक्ष्म संदर्भ है (जो परस्पर महत्वपूर्ण प्रकारों को सबसे बड़ी सार्वभौमिक बुराई मानता है), जिसमें वह "उल्लेखनीय रूप से स्पष्ट नहीं" व्यवहार दिखाता है जब आईडीएसआरोप्य इंटरफ़ेस को लागू करने वाले पारस्परिक महत्वपूर्ण प्रकारों का उपयोग करने के लिए बॉक्स या नहीं। बॉक्स के लिए, यह एक सवाल है ।