सी #: पिछड़े संगतता और अधिभार

नमस्कार साथियों!

हम सभी को याद दिलाते हैं कि हमारे पास एक महान मार्क प्राइस बुक है, " सी # 7 और .NET कोर। पेशेवरों के लिए क्रॉस-प्लेटफॉर्म विकास ।" कृपया ध्यान दें: यह तीसरा संस्करण है, पहला संस्करण 6.0 संस्करण में लिखा गया था और रूसी में दिखाई नहीं दिया था, और तीसरा संस्करण मूल रूप से नवंबर 2017 में जारी किया गया था और संस्करण 7.1 शामिल है।


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

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

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

स्रोत और बाइनरी संगतता

यदि मैं लाइब्रेरी के नए संस्करण के साथ अपने क्लाइंट कोड को फिर से जोड़ सकता हूं, और सब कुछ ठीक काम करता है, तो यह स्रोत कोड स्तर पर संगतता है। अगर मैं अपने क्लाइंट बाइनरी को फिर से जमा किए बिना लाइब्रेरी के नए संस्करण के साथ फिर से तैयार कर सकता हूं, तो यह बाइनरी संगत है। इनमें से कोई भी दूसरे का सुपरसेट नहीं है:

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

तो हम किस बारे में बात कर रहे हैं?

मान लीजिए हमारे पास 1.0 संस्करण की सार्वजनिक लाइब्रेरी है, और हम संस्करण 1.1 को अंतिम रूप देने के लिए इसमें कई अतिभार जोड़ सकते हैं। हम सिमेंटिक वर्जनिंग से चिपके रहते हैं, इसलिए हमें बैकवर्ड कम्पैटिबिलिटी चाहिए। इसका क्या मतलब है कि हम कर सकते हैं और नहीं कर सकते हैं, और क्या यहां सभी सवालों का जवाब "हां" या "नहीं" हो सकता है?

विभिन्न उदाहरणों में, मैं कोड को 1.0 और 1.1 संस्करणों में दिखाऊंगा, और फिर "क्लाइंट" कोड (यानी, कोड जो लाइब्रेरी का उपयोग करता है), जो परिवर्तनों के परिणामस्वरूप टूट सकता है। न तो विधि निकाय होंगे, न ही वर्ग घोषणाएं, क्योंकि वे हैं, संक्षेप में, महत्वपूर्ण नहीं - हम हस्ताक्षर पर मुख्य ध्यान देते हैं। हालांकि, यदि आप रुचि रखते हैं, तो इन सभी वर्गों और विधियों को आसानी से पुन: पेश किया जा सकता है। मान लीजिए कि यहां वर्णित सभी विधियां Library क्लास में हैं।

एक प्रतिनिधि के लिए तरीकों का एक समूह के परिवर्तन के साथ सजी सबसे सरल बोधगम्य परिवर्तन
मेरे दिमाग में आने वाला सबसे सरल उदाहरण एक मानकीकृत पद्धति को जोड़ना है जहां पहले से ही गैर-पैरामीटरित एक है:

  //   1.0 public void Foo() //   1.1 public void Foo() public void Foo(int x) 

यहां भी, संगतता अधूरी है। निम्नलिखित ग्राहक कोड पर विचार करें:

  //  static void Method() { var library = new Library(); HandleAction(library.Foo); } static void HandleAction(Action action) {} static void HandleAction(Action<int> action) {} 

पुस्तकालय के पहले संस्करण में, सब कुछ ठीक है। HandleAction विधि को HandleAction library.Foo के समूह को library.Foo परिवर्तित करता है। प्रतिनिधियों को HandleAction , और परिणामस्‍वरूप, एक Action बनाई जाती है। संस्करण 1.1 में, स्थिति अस्पष्ट हो जाती है: तरीकों के एक समूह को एक्शन या एक्शन में परिवर्तित किया जा सकता है। यही है, सख्ती से बोल रहा हूं, इस तरह के बदलाव स्रोत कोड के साथ असंगत हैं।

इस स्तर पर, यह सिर्फ हार मानने का प्रलोभन है और अपने आप से वादा करें कि किसी भी ओवरलोड को फिर कभी न जोड़ें। या हम कह सकते हैं कि इस तरह के एक मामले में ऐसी विफलता से डरने की संभावना नहीं है। आइए अब इसके लिए तरीकों के एक समूह के परिवर्तनों को दायरे से बाहर करें।

असंबंधित संदर्भ प्रकार

एक और संदर्भ पर विचार करें जहां आपको एक ही संख्या के मापदंडों के साथ ओवरलोड का उपयोग करना है। यह माना जा सकता है कि पुस्तकालय में ऐसा बदलाव गैर-विनाशकारी होगा:

 //  1.0 public void Foo(string x) //  1.1 public void Foo(string x) public void Foo(FileStream x) 

पहली नज़र में, सब कुछ तार्किक है। हम मूल विधि रखते हैं, इसलिए हम बाइनरी संगतता को नहीं तोड़ेंगे। इसे तोड़ने का सबसे सरल तरीका एक कॉल लिखना है जो v1.0 में काम करता है, लेकिन v1.1 में काम नहीं करता है, या दोनों संस्करणों में काम करता है, लेकिन अलग-अलग तरीकों से।
V1.0 और v1.1 के बीच क्या असंगति ऐसी कॉल दे सकती है? हमारे पास string और FileStream दोनों के साथ संगत तर्क होना चाहिए। लेकिन ये संदर्भ प्रकार एक दूसरे से संबंधित नहीं हैं ...

यदि हम एक उपयोगकर्ता-परिभाषित अंतर्निहित रूपांतरण दोनों string और FileStream करते हैं तो पहली विफलता संभव है:

 //  class OddlyConvertible { public static implicit operator string(OddlyConvertible c) => null; public static implicit operator FileStream(OddlyConvertible c) => null; } static void Method() { var library = new Library(); var convertible = new OddlyConvertible(); library.Foo(convertible); } 

मुझे उम्मीद है कि समस्या स्पष्ट है: कोड जो पहले अस्पष्ट था और string साथ काम किया गया था, अब अस्पष्ट है, क्योंकि OddlyConvertible प्रकार को दोनों string और FileStream परिवर्तित किया जा सकता है (दोनों अधिभार लागू होते हैं, दोनों में से कोई भी बेहतर नहीं है)।

हो सकता है कि इस मामले में उपयोगकर्ता द्वारा परिभाषित रूपांतरणों पर रोक लगाना उचित हो ... लेकिन इस कोड को नीचे लाया जा सकता है और बहुत आसान:

 //  static void Method() { var library = new Library(); library.Foo(null); } 

हम स्पष्ट रूप से किसी भी संदर्भ प्रकार या किसी भी उल्लेखनीय महत्वपूर्ण प्रकार के लिए एक अशक्त शाब्दिक रूपांतरित कर सकते हैं ... इसलिए, फिर से, संस्करण 1.1 में स्थिति अस्पष्ट है। चलिए फिर कोशिश करते हैं ...

संदर्भ प्रकार और गैर-अशक्त महत्वपूर्ण प्रकार के पैरामीटर

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

  //  1.0 public void Foo(string x) //  1.1 public void Foo(string x) public void Foo(int x) 

पहली नज़र में, यह अच्छा है - library.Foo(null) v1.1 में ठीक काम करेगा। तो क्या वह सुरक्षित है? नहीं, सिर्फ C # 7.1 में नहीं ...

  //  static void Method() { var library = new Library(); library.Foo(default); } 

डिफ़ॉल्ट शाब्दिक रूप से शून्य है, लेकिन किसी भी प्रकार पर लागू होता है। यह बहुत सुविधाजनक है - और एक वास्तविक सिरदर्द जब यह अधिभार और संगतता के लिए आता है :(

वैकल्पिक पैरामीटर

वैकल्पिक पैरामीटर एक और समस्या है। मान लीजिए कि हमारे पास एक वैकल्पिक पैरामीटर है, और हम एक दूसरा जोड़ना चाहते हैं। हमारे पास तीन विकल्प हैं, जिन्हें हम 1.1a, 1.1b और 1.1c के रूप में पहचानते हैं।

  //  1.0 public void Foo(string x = "") //  1.1a //   ,         public void Foo(string x = "") public void Foo(string x = "", string y = "") //  1.1b //          public void Foo(string x = "", string y = "") //  1.1c //   ,    ,   //  ,     . public void Foo(string x) public void Foo(string x = "", string y = "") 

लेकिन क्या होगा अगर ग्राहक दो कॉल करता है:

 //  static void Method() { var library = new Library(); library.Foo(); library.Foo("xyz"); } 

लाइब्रेरी 1.1a द्विआधारी स्तर पर संगतता बनाए रखता है, लेकिन स्रोत कोड स्तर पर उल्लंघन करता है: अब library.Foo() अस्पष्ट है। C # में अधिभार नियमों के अनुसार, उन तरीकों को प्राथमिकता दी जाती है जो सभी उपलब्ध वैकल्पिक मापदंडों में "भरने" के लिए कंपाइलर की आवश्यकता नहीं होती है, हालांकि, यह विनियमित नहीं करता है कि कितने वैकल्पिक पैरामीटर भरे जा सकते हैं।

लाइब्रेरी 1.1b स्रोत स्तर की संगतता बनाए रखता है, लेकिन बाइनरी संगतता का उल्लंघन करता है। मौजूदा संकलित कोड को एकल पैरामीटर के साथ एक विधि को कॉल करने के लिए डिज़ाइन किया गया है - और ऐसी विधि अब मौजूद नहीं है।

1.1c पुस्तकालय द्विआधारी संगतता को बरकरार रखता है, लेकिन स्रोत कोड स्तर पर संभावित आश्चर्य से भरा है। अब library.Foo() कॉल को दो मापदंडों के साथ एक विधि में हल किया जाता है, जबकि library.Foo("xyz") एक पैरामीटर के साथ एक विधि में हल किया जाता है (संकलक के दृष्टिकोण से, यह दो मापदंडों के साथ एक विधि के लिए बेहतर है, मुख्यतः क्योंकि कोई वैकल्पिक पैरामीटर नहीं हैं। कोई भरने की आवश्यकता नहीं)। यह स्वीकार्य हो सकता है यदि एक पैरामीटर वाला एक संस्करण केवल दो मापदंडों के साथ संस्करणों को दर्शाता है, और दोनों ही मामलों में एक ही डिफ़ॉल्ट मान का उपयोग किया जाता है। हालांकि, यह अजीब लगता है कि पहली कॉल का मूल्य बदल जाएगा यदि वह विधि जिसे पहले हल किया गया था वह अभी भी मौजूद है।

वैकल्पिक मापदंडों के साथ स्थिति और भी भ्रामक हो जाती है यदि आप अंत में नया पैरामीटर नहीं जोड़ना चाहते हैं, लेकिन बीच में - उदाहरण के लिए, समझौते का पालन करने का प्रयास करें और वैकल्पिक कैंसिलेशन टोकन पैरामीटर को बहुत अंत में रखें। मैं इसमें नहीं जाऊंगा ...

सामान्यीकृत तरीके

सर्वोत्तम समय में प्रकारों का समापन एक आसान काम नहीं था। जब यह अधिभार को हल करने की बात आती है, तो यह काम एक समान दुःस्वप्न में बदल जाता है।

मान लीजिए कि हमारे पास v1.0 में केवल एक गैर-सामान्यीकृत विधि है, और v1.1 में हम एक और सामान्यीकृत विधि जोड़ते हैं।

 //  1.0 public void Foo(object x) //  1.1 public void Foo(object x) public void Foo<T>(T x) 

पहली नज़र में, यह इतना डरावना नहीं है ... लेकिन ग्राहक कोड में क्या होता है आइए देखें:

 //  static void Method() { var library = new Library(); library.Foo(new object()); library.Foo("xyz"); } 

लाइब्रेरी v1.0 में, दोनों कॉल Foo(object) में हल किए गए हैं - केवल उपलब्ध विधि।

V1.1 पुस्तकालय पीछे की ओर संगत है: यदि आप v1.1 के लिए संकलित निष्पादन योग्य ग्राहक फ़ाइल लेते हैं, तो दोनों कॉल अभी भी Foo(object) उपयोग करेंगे। लेकिन, पुनर्संयोजन के मामले में, दूसरी कॉल (और केवल दूसरी) सामान्यीकृत विधि के साथ काम करने के लिए स्विच करेगी। दोनों तरीकों दोनों कॉल पर लागू होते हैं।

पहली कॉल पर, टाइप इंट्रेंस दिखाएगा कि T एक object , इसलिए तर्क को पैरामीटर प्रकार में परिवर्तित करना दोनों ही मामलों में object में object को कम कर देगा। बहुत बढ़िया। कंपाइलर नियम लागू करेगा कि गैर-सामान्य तरीके हमेशा जेनेरिक के लिए बेहतर होते हैं।

दूसरी कॉल पर, टाइप इंट्रेंस दिखाएगा कि T हमेशा string , इसलिए किसी तर्क को एक प्रकार के पैरामीटर में परिवर्तित करते समय, हम मूल विधि के लिए object लिए string या सामान्यीकृत विधि के लिए string से string प्राप्त करते हैं। दूसरा परिवर्तन "बेहतर" है, इसलिए दूसरी विधि चुनी गई है।

यदि दो तरीके एक ही तरीके से काम करते हैं, तो ठीक है। यदि नहीं, तो आप संगतता को बहुत ही गैर-स्पष्ट तरीके से तोड़ देंगे।

वंशानुक्रम और गतिशील टाइपिंग

क्षमा करें, मैं पहले ही सांस से बाहर हूँ। ओवरलोड को हल करते समय वंशानुक्रम और गतिशील टाइपिंग दोनों सबसे "शांत" और रहस्यमय तरीके से खुद को प्रकट कर सकते हैं।
यदि हम वंशानुक्रम पदानुक्रम के एक स्तर पर ऐसी विधि जोड़ते हैं जो आधार वर्ग की विधि को अधिभारित करेगा, तो नई विधि को पहले संसाधित किया जाएगा और आधार वर्ग की पद्धति को पसंद किया जाएगा, भले ही एक प्रकार के पैरामीटर में एक तर्क को परिवर्तित करते समय आधार वर्ग की विधि अधिक सटीक हो। सब कुछ मिलाने के लिए पर्याप्त जगह है।

वही डायनेमिक टाइपिंग के लिए जाता है (क्लाइंट कोड में); कुछ हद तक, स्थिति अप्रत्याशित हो जाती है। आपने पहले ही संकलन के दौरान सुरक्षा को गंभीरता से त्याग दिया है ... इसलिए अगर कुछ टूटता है तो आश्चर्यचकित न हों।

परिणाम

मैंने इस लेख में उदाहरणों को काफी सरल बनाने की कोशिश की। सब कुछ बहुत जटिल हो जाता है, और बहुत जल्दी, जब आपके पास बहुत सारे वैकल्पिक पैरामीटर होते हैं। संस्करण बनाना एक जटिल मामला है, मेरा सिर इससे सूज जाता है।