C # .NET में ऑब्जेक्ट्स की तुलना करना

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

तो, System.Object वर्ग निम्नलिखित तरीके प्रदान करता है:

• public static bool ReferenceEquals(object objA, object objB) { return objA == objB; } 

  
  

•  public static bool Equals(object objA, object objB) { return objA == objB || (objA != null && objB != null && objA.Equals(objB)); } 

  
  

•  public virtual bool Equals(object obj) { return RuntimeHelpers.Equals(this, obj); } 

  
  

अच्छी तरह से और:

 public static bool operator == (Foo left, Foo right); 

यह भी IEquatable, IStructuralEquatable वारिस करने के लिए संभव है।

ReferenceEquals

ReferenceEquals विधि दो लिंक की तुलना करती है। यदि वस्तुओं के संदर्भ समान हैं, तो सही है। इसका मतलब है कि यह विधि समानता के लिए उदाहरणों की जांच नहीं करती है, लेकिन पहचान के लिए। यदि आप इस विधि के लिए एक महत्वपूर्ण प्रकार के उदाहरणों को पास करते हैं (भले ही आप उसी उदाहरण को पास करते हैं), तो यह हमेशा गलत होगा। ऐसा इसलिए होगा क्योंकि स्थानांतरण के दौरान महत्वपूर्ण प्रकारों की पैकेजिंग होगी और उनके लिंक अलग-अलग होंगे।
यहाँ, मैं इस विधि द्वारा दो लाइनों की तुलना का उल्लेख करना चाहूंगा। उदाहरण के लिए:

 class Program { static void Main(string[] args) { string a = "Hello"; string b = "Hello"; if(object.ReferenceEquals(a,b)) Console.WriteLine("Same objects"); else Console.WriteLine("Not the same objects"); Console.ReadLine(); } } 

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

सार्वजनिक स्थैतिक बूल बराबर (ऑब्जेक्ट objA, ऑब्जेक्ट objB)

सबसे पहले, यह विधि पहचान के लिए उदाहरणों की जांच करती है, और यदि ऑब्जेक्ट समान नहीं होते हैं, तो यह उन्हें अशक्त के लिए जांचता है और पुनर्निर्धारित आवृत्ति विधि की तुलना करने के लिए जिम्मेदारी को बराबर करता है।

सार्वजनिक वर्चुअल बूल बराबर (ऑब्जेक्ट obj)

डिफ़ॉल्ट रूप से, यह विधि बिल्कुल ReferenceEquals की तरह व्यवहार करती है। हालाँकि, सार्थक प्रकारों के लिए, यह System.ValueType में निम्नानुसार ओवरराइड है:

 public override bool Equals(object obj) { if (obj == null) { return false; } RuntimeType runtimeType = (RuntimeType)base.GetType(); RuntimeType left = (RuntimeType)obj.GetType(); if (left != runtimeType) { return false; } if (ValueType.CanCompareBits(this)) { return ValueType.FastEqualsCheck(this, obj); } FieldInfo[] fields = runtimeType.GetFields(BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic); for (int i = 0; i < fields.Length; i++) { object obj2 = ((RtFieldInfo)fields[i]).InternalGetValue(this, false); object obj3 = ((RtFieldInfo)fields[i]).InternalGetValue(obj, false); if (obj2 == null) { if (obj3 != null) { return false; } } else { if (!obj2.Equals(obj3)) { return false; } } } return true; } 

भगवान किसी को भी बड़े सेट पर इस तरह के कार्यान्वयन का उपयोग करने से मना करते हैं। BCL डेवलपर्स यह नहीं जान सकते हैं कि हम इन क्षेत्रों के बारे में अग्रिम रूप से कुछ भी जाने बिना प्रतिबिंब के उपयोग से अपने क्षेत्रों द्वारा महत्वपूर्ण प्रकारों को किस प्रकार परिभाषित करेंगे और तुलना करेंगे। बेशक, यह तुलना का बहुत उत्पादक तरीका नहीं है। इसलिए, संकलन चरण में ज्ञात महत्वपूर्ण प्रकारों का उपयोग करते समय, आपको इस विधि को ओवरराइड करना चाहिए, क्योंकि आपसे बेहतर कौन यह जान सकता है कि आपके द्वारा विकसित दो वस्तुओं की तुलना कैसे की जाए? संदर्भ प्रकारों के लिए, महत्वपूर्ण प्रकारों में दो उदाहरणों की तुलना करने की आवश्यकता के बिना, इस पद्धति को ओवरराइड करना वैकल्पिक है।
आइए इस पद्धति के एक सक्षम पुनर्निर्देशन के एक उदाहरण को देखें और तुरंत IEquatable को लागू करें:

 class Vehicle:IEquatable<Vehicle> { protected int speed; public int Speed { get { return this.speed; } set { this.speed = value; } } protected string name; public string Name { get { return this.name; } set { this.name = value; } } public Vehicle(){} public Vehicle(int speed, string name) { this.speed = speed; this.name = name; } public override bool Equals(object other) { //     . //    null  other,  other.GetType()   //NullReferenceException. if (other == null) return false; //        ,    . if (object.ReferenceEquals(this, other)) return true; //          ,    // Vehicle tmp = other as Vehicle; if(tmp==null) return false; //   ,     tmp. if (this.GetType() != other.GetType()) return false; return this.Equals(other as Vehicle); } public bool Equals(Vehicle other) { if (other == null) return false; //    . //  ,            - // . if (object.ReferenceEquals(this, other)) return true; //   ,         , //           . if (this.GetType() != other.GetType()) return false; if (string.Compare(this.Name, other.Name, StringComparison.CurrentCulture) == 0 && this.speed.Equals(other.speed)) return true; else return false; } } 

वर्चुअल विधि को फिर से परिभाषित करने में पदानुक्रम के शीर्ष के बारे में टिप्पणी एक कारण से की जाती है। यदि आप वाहन वर्ग (उदाहरण के लिए, बाइक) का एक इनहेरीटर बनाते हैं, जिसमें एक ओवरराइड वर्चुअल इक्वाल्स विधि भी होगी, जिसमें गेटटाइप द्वारा किसी प्रकार की तुलना नहीं की जाएगी, लेकिन Bike tmp = other as Bike; if(tmp!=null) this.Equals(tmp); डालने का प्रयास Bike tmp = other as Bike; if(tmp!=null) this.Equals(tmp); Bike tmp = other as Bike; if(tmp!=null) this.Equals(tmp); तब इस स्थिति में, निम्न कोड समस्याएँ पैदा कर सकते हैं:

 Vehicle vehicle = new Vehicle(); Bike bike = new Bike(); object vehicleObj = vehicle; object bikeObject = bike; bike.Equals(vehicleObj); //      .  ,   //     

सार्वजनिक स्थिर बूल ऑपरेटर == (फू बाएं, फू दाएं)

सार्थक प्रकारों के लिए, आपको हमेशा वर्चुअल समान () की तरह इसे फिर से परिभाषित करना चाहिए। संदर्भ प्रकारों के लिए, इसे ओवरराइड नहीं करना बेहतर है, क्योंकि, संदर्भ प्रकारों पर, == से डिफ़ॉल्ट रूप से, व्यवहार संदर्भांक () पद्धति के अनुसार अपेक्षित है। तो, यहाँ सब कुछ सरल है।

IStructuralEquatable

IStructuralEquitable IEqualityComparer इंटरफ़ेस के साथ हाथ में हाथ जाता है। IStructuralEquitable इंटरफ़ेस, System.Array या System.Tuple जैसी कक्षाओं द्वारा कार्यान्वित किया जाता है। बिल वैगनर के अनुसार, IStructuralEquality घोषणा करता है कि एक प्रकार बड़ी वस्तुओं का गठन कर सकता है जो महत्वपूर्ण प्रकारों के शब्दार्थ को लागू करते हैं और यह संभावना नहीं है कि हमें कभी भी इसे स्वयं लागू करने की आवश्यकता होगी। हालांकि, इसके कार्यान्वयन में क्या मुश्किल है? केवल System.Array में इसके कार्यान्वयन को देखें:

 bool IStructuralEquatable.Equals(object other, IEqualityComparer comparer) { if (other == null) { return false; } if (object.ReferenceEquals(this, other)) { return true; } Array array = other as Array; if (array == null || array.Length != this.Length) { return false; } for (int i = 0; i < array.Length; i++) { object value = this.GetValue(i); object value2 = array.GetValue(i); if (!comparer.Equals(value, value2)) { return false; } } return true; } 

दरअसल, वस्तुओं की पहचान को पहले जांचा जाता है, फिर उन्हें उसी प्रकार का बनाया जाता है और लंबाई की तुलना की जाती है। यदि लंबाई बराबर है, तो समान इंटरफ़ेस विधि (IEqualityComparent) की तुलना में इसके लिए जिम्मेदारी सौंपकर तत्ववाचक तुलना शुरू होती है।

यह अनिवार्य रूप से वह सब है जो C # .NET में वस्तुओं की तुलना करने के बारे में कहा जा सकता है, लेकिन एक और छोटा लेकिन महत्वपूर्ण विवरण रहता है: GetHashCode () विधि।

सार्वजनिक वर्चुअल int GetHashCode ()

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

 internal sealed class Point { private int a; private int b; public override int GetHashCode() { return a ^ b; } } 

और यहाँ कैसे GetHasCode () को System.Char में पुनः परिभाषित किया गया है:

 public override int GetHashCode() { return (int)this | (int)this << 16; } 

कई उदाहरण दिए जा सकते हैं, और अनुमानी संकेतकों को लगभग हर जगह पाली के लिए उपयोग किया जाता है जो बाहर या इतने पर।

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


यहाँ अनुवाद करें