एक और कारण संरचनाएं खराब हैं

दिलचस्प बिंदु के साथ काम पर सामना किया। परियोजना में, सभी छोटे डेटा ट्रांसफर ऑब्जेक्ट संरचनाओं द्वारा किए जाते हैं। यह क्यों किया गया था, इस सवाल पर, मुझे जवाब मिला कि इस तरह से डेटा को परिवर्तनों से सुरक्षित किया जाता है। एक तरफ, हाँ, यह लगता है, सिद्धांत रूप में, तार्किक, कोई भी विधि केवल एक प्रति प्राप्त करती है और कुछ भी बदलने में सक्षम नहीं होती है।



लेकिन दूसरी ओर, यह दृष्टिकोण हल करने की तुलना में कहीं अधिक समस्याओं को वहन करता है।



सबसे पहले, संरचनाओं का उपयोग प्रदर्शन और मेमोरी दोनों को हिट करता है। प्रत्येक कॉल एक प्रति है, संरचनाओं के किसी भी सरणी को बड़े ऑब्जेक्ट हीप में गिरने की लगभग गारंटी है, जो दोनों प्रदर्शन (जीसी में बढ़े हुए समय के कारण) और मेमोरी (खंडित हीप बहुत खराब) है।



दूसरे, संरचनाओं का उपयोग त्रुटियों से भरा है। उदाहरण के लिए:

class Program

{

static void Main( string [] args)

{

Foo[] f = new [] { new Foo {Field = 5}};



for ( int i = 0; i < f.Length; i++)

{

Foo foo = f[i];

foo.Field = 10;

Console .WriteLine(foo.Field);

}



Console .WriteLine(f[0].Field);

}

}

struct Foo

{

public int Field;

}



* This source code was highlighted with Source Code Highlighter .

स्क्रीन, निश्चित रूप से प्रदर्शित होगी,

 10
 5

लेकिन यह तथ्य कि यह "पाठ्यक्रम" कोड के सावधानीपूर्वक अध्ययन के बाद ही स्पष्ट हो जाएगा, और, केवल आईडीई के साथ - यह समझने के लिए कि फू किसी भी अन्य दर्शक में एक संरचना है लगभग असंभव है, खासकर अगर फू किसी अन्य परियोजना में परिभाषित किया गया है। .NET डेवलपर्स लिंक के साथ काम करने के आदी हैं (जो, संयोगवश, रिस्पेपर में बग द्वारा स्पष्ट रूप से प्रतिध्वनित होता है - वह सुझाव देता है कि 'फॉर' साइकल विद 'फॉरचेक', जो कि निकलता है, असंभव है)।



और तीसरा, वास्तव में, "सुरक्षा" की भावना भ्रामक है। इन संरचनाओं में अक्सर ऐरे पाए जाते हैं (भले ही संरचनाएं हों), जो इन "अपरिवर्तनीय" संरचनाओं को "अपरिवर्तनीय" नहीं बनाता है। उदाहरण के लिए:

class Program

{

static void Main( string [] args)

{

Foo f = new Foo

{

Field = 5,

Bars = new []

{

new Bar {Name = "My Name" }

}

};



BadFunction(f);

Console .WriteLine(f.Bars[0].Name);

}



private static void BadFunction(Foo foo)

{

foo.Field = 10;

foo.Bars[0] = new Bar {Name = "Other Name" };

}

}

struct Foo

{

public int Field;

public Bar[] Bars;

}

struct Bar

{

public string Name;

}



* This source code was highlighted with Source Code Highlighter .

निष्पादन के बाद, आप "अन्य नाम" देखेंगे, जो बिल्कुल तार्किक है और यह भी स्पष्ट होगा कि फू कोई संरचना नहीं थी, बल्कि एक वर्ग था। लेकिन संरचनाओं के मामले में, यह समझने के लिए कि डेवलपर केवल सरणी में मूल्य को बदलना चाहता था, और छद्म-अदृश्य जाल में नहीं गिरा, फिर से, बहुत मुश्किल है।



निष्कर्ष स्वयं का सुझाव देते हैं (बेशक, किसी ने सामान्य ज्ञान और विशेष मामलों को रद्द नहीं किया है):

1. केवल उन संरचनाओं का उपयोग करें जहां यह वास्तव में आवश्यक है और उचित है (उदाहरण के लिए P / Invoke)।
   
   
2. रिटर्न प्रकार के रूप में सरणियों का उपयोग न करें - चरम मामलों में IEnumerable <T> या, IList <T> का उपयोग करें (लेकिन केवल ReadOnlyCollection <T> के रूप में)।
   
   
3. यदि आप वास्तव में संरचनाओं का उपयोग करते हैं, तो उन्हें वास्तव में अपरिवर्तनीय बनाएं।