डेटा स्थानांतरण ऑब्जेक्ट के लिए दो सबसे अच्छे विकल्प आमतौर पर एक गहराई से अपरिवर्तनीय वर्ग वस्तु या डेटा हस्तांतरण ऑब्जेक्ट्स के रूप में उपयोग के लिए उपयुक्त प्रकार के उजागर क्षेत्रों के साथ एक संरचना होनी चाहिए। अन्य प्रकार के structs कभी-कभी उपयोग करने योग्य भी हो सकते हैं, लेकिन खुला-क्षेत्रीय structs अब तक सबसे सरल हैं, और यह सादगी एक महान गुण है।
धारणा है कि परिवर्तनशील structs बुराई दिनांकों वापस कुछ जल्दी सी # संकलक करने के लिए जो कर रहे हैं, जिसमें
SomeReadonlyStruct.SomeProperty = 5;
चुपचाप में संकलक से बदल दिया जाएगा: केवल पढ़ने के गुण के पीछे
var temp = SomeReadonlyStruct;
temp.SomeProperty = 5;
struct क्षेत्रों छिपाई जा रही है यह सुनिश्चित करने का प्रयास था कि पूर्व कथन टूटा हुआ कोड देने के बजाय संकलन करने से इंकार कर देगा। चूंकि नए कंपाइलर रीडोनली structs के लिखने योग्य क्षेत्रों को म्यूट करने से इनकार कर देंगे, अब केवल पढ़ने योग्य गुणों में फ़ील्ड को लपेटने की आवश्यकता नहीं है।
उजागर क्षेत्रों के साथ स्ट्रक्चर अन्य प्रकार के डेटा ट्रांसफर ऑब्जेक्ट्स की तुलना में एक बड़ा फायदा होता है: प्रत्येक संरचना जिसने डेटा-ट्रांसफर के लिए उपयुक्त प्रकार के क्षेत्रों का खुलासा किया है और कोई अन्य सदस्य अन्यथा छोड़कर एक कन्स्ट्रक्टर को वैसे ही व्यवहार करता है, बिना आश्चर्य। कोई भी जिसने कभी भी structs का उपयोग नहीं किया है, इस तथ्य से थोड़ा आश्चर्यचकित हो सकता है कि वे कक्षाओं की तरह कार्य नहीं करते हैं, लेकिन कोई भी जो समझता है कि इस तरह के किसी भी संरचना कार्य कैसे समझेंगे कि वे सभी कैसे काम करते हैं।
पर विचार करें निम्नलिखित कोड:
customerPhone = someDataSource.GetPhoneNumber(customerID);
customerPhone.Extention = "5309"
कुछ लोगों को तथ्य यह है कि अगर customerPhone एक उजागर मैदान struct है, Extension संपत्ति की स्थापना someDataSource में जानकारी को प्रभावित नहीं करेगा नापसंद करते हैं। हालांकि यह निश्चित रूप से सच है कि एक संरचना क्षेत्र लिखना किसी और चीज को अपडेट नहीं करेगा, यह customerPhone एक परिवर्तनीय वर्ग प्रकार था, तो यह अस्तित्व की तुलना में एक बेहतर स्थिति है। कोई भी जो customerPhone समझता है, एक खुला क्षेत्रीय संरचना प्रकार पता चलेगा कि उसके सदस्यों में परिवर्तन किसी और चीज को प्रभावित नहीं करेंगे। इसके विपरीत, यदि customerPhone एक म्यूटेबल क्लास प्रकार है, तो ऊपर दिए गए कोड को customerID से जुड़े फ़ोन नंबर को बदलकर अपडेट कर सकते हैं। या यह नहीं हो सकता है। या, यदि एक फोन नंबर दो customerID मानों से जुड़ा हुआ था, तो उपर्युक्त कोड दोनों को बदल सकता है। कोड कोड की मात्रा को यह निर्धारित करने के लिए अध्ययन करना पड़ सकता है कि उपर्युक्त कोड के प्रभाव और दुष्प्रभाव कितने बड़े हो सकते हैं। इससे भी बदतर, यह सुनिश्चित करना मुश्किल हो सकता है कि किसी ने कुछ भी याद नहीं किया है।
निश्चित रूप से कुछ जगहें हैं जहां कक्षा ऑब्जेक्ट संदर्भों के चारों ओर गुज़रने से structs के चारों ओर गुजरने से अधिक कुशल हो सकता है। ऐसे कुछ मामले भी हैं जहां म्यूटेबल क्लास ऑब्जेक्ट्स कक्षा के भीतर उपयोगी डेटा धारक हो सकते हैं। कुछ जेनेरिक रैपर, हालांकि, एक परिवर्तनीय या अपरिवर्तनीय वर्ग, में एक संरचना को लपेटने और उन प्रकार के वर्गों के बीच की जानकारी का आदान-प्रदान करने में सक्षम हो सकते हैं।
interface IReadableHolder<T> { T Value {get;} }
class MutableHolder<T> : IReadableHolder<T>
{
public T Value;
IReadableHolder.Value {get {return Value;} }
public MutableHolder(T newValue) { Value = newValue; }
public MutableHolder(IReadableHolder<T> it) { Value = it.Value; }
}
class ImmutableHolder<T> : IReadableHolder<T>
{
T _Value;
public Value {get {return _Value;} }
public ImmutableHolder(T newValue) { _Value = newValue; }
}
ऐसा निर्माण म्यूटेबल structs के बिना और अधिक अजीब होगा।
"कक्षा" (यह एक आसान था; पी) –
सभी भाग लेने के लिए धन्यवाद! –