इंटरफ़ेस विरासत और अनुबंध

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

यह दो विशेषताओं का उपयोग करके हल किया गया है: ContractClassAttribute , जो इंटरफ़ेस या अमूर्त वर्ग पर लटका दिया गया है, और ContractClassForAttribute - जिसे अनुबंध पर ही लटका दिया गया है।

/// <summary> /// Custom collection interface /// </summary> [ContractClass(typeof(CollectionContract))] public interface ICollection { void Add(string s); int Count { get; } bool Contains(string s); } /// <summary> /// Contract class for <see cref="ICollection"/>. /// </summary> [ContractClassFor(typeof(ICollection))] internal abstract class CollectionContract : ICollection { public void Add(string s) { Contract.Ensures(Count >= Contract.OldValue(Count)); Contract.Ensures(Contains(s)); } public int Count { get { Contract.Ensures(Contract.Result<int>() >= 0); return default(int); } } [Pure] public bool Contains(string s) { return default(bool); } } 

इस ICollection इंटरफ़ेस की उपयोगिता संदिग्ध लगती है, लेकिन उनकी मदद से हम इंटरफेस की विरासत के संबंध में सभी आवश्यक सुविधाओं और अनुबंधों की सीमाओं को देख सकते हैं। इस उदाहरण में फोकस कलेक्शनकंट्रेक वर्ग के दो सदस्यों पर है: जोड़ें विधि और गणना गुण, जो संबंधित विधियों के पूर्व शर्त / पोस्टकंड निर्दिष्ट करते हैं।

अब, यदि कुछ वर्ग हमारे ICollection इंटरफ़ेस को लागू करते हैं और पोस्टकॉन्डिशन का उल्लंघन करते हैं, तो हम इसे रनटाइम पर एक अपवाद के रूप में देखेंगे (एक निश्चित CONTRACT_FULL वर्ण के साथ), और संभवतः, स्टेटिक कोड विश्लेषण के दौरान स्टेटिक चेकर के दौरान भी:

 internal class CustomCollection : ICollection { private readonly List<string> _backingList = new List<string>(); public void Add(string s) { // Ok, we're crazy enough to violate precondition // of ICollection interface if (Contains(s)) _backingList.Remove(s); else _backingList.Add(s); } public int Count { get { // We should add some hints to static checker to eliminate a warning Contract.Ensures(Contract.Result<int>() == _backingList.Count); return _backingList.Count; } } public bool Contains(string s) { return _backingList.Contains(s); } } 

इस स्थिति में, यह ठीक वैसा ही होता है: स्टेटिक चेकर निर्धारित करता है कि कुछ मामलों में ऐड मेथड का उत्तर संतुष्ट नहीं है (जब किसी मौजूदा तत्व को जोड़ते हैं, तो हम इसे हटाते हैं)। लेकिन अगर हम उस पर विश्वास नहीं करते हैं, तो हम निष्पादन के दौरान अनुबंध का उल्लंघन देख सकते हैं।

 [Test] public void TestAddTwiceAddsTwoElements() { var collection = new CustomCollection(); int oldCount = collection.Count; collection.Add(""); collection.Add(""); Assert.That(collection.Count, Is.EqualTo(oldCount + 2)); } 

जब Assert कहा जाता है तो यह परीक्षण विफल हो जाता है । वह , और इससे पहले, जब अपवाद के साथ फिर से ऐड मेथड को कॉल करने की कोशिश कर रहा था: System.Diagnostics.Contracts .__ ContractsRuntime + ContractException: पोस्टकंडिशन विफल: काउंट> = Contract.OldValue (काउंट)

नोट
स्टैटिक विश्लेषण "कॉन्ट्रैक्ट प्रोग्रामिंग" की सबसे दिलचस्प विशेषताओं में से एक है, लेकिन अब हम सुरक्षित रूप से कह सकते हैं कि कोड कॉन्ट्रैक्ट्स लाइब्रेरी में यह चीज़ अभी तक वास्तविक परियोजनाओं के लिए तैयार नहीं है। सबसे पहले, संकलन का समय परिमाण के एक क्रम से बढ़ सकता है (!), और दूसरी बात, इसके चारों ओर आपको एक तंबू के साथ बचकाना कूदना होगा ताकि वह समझ सके कि क्या हो रहा है, लेकिन इस मामले में भी वह मुश्किल मामलों में मदद करने के लिए बहुत कम हो सकता है। यहां तक ​​कि CustomCollection वर्ग के साथ इस तरह के एक सरल उदाहरण में, मुझे मैन्युअल रूप से गिनती संपत्ति में एक पोस्टऑनडिशन जोड़ना पड़ा, क्योंकि इसके बिना स्थैतिक विश्लेषक समझ नहीं पाए कि क्या हो रहा था और चेतावनी का एक गुच्छा दिया। अनुबंध के अन्य सभी लाभ, जैसे कि घोषणा, प्रलेखन, संबंधों की औपचारिकता, आदि। बने रहें, लेकिन वे रनटाइम पर काम करेंगे (उदाहरण के लिए, यूनिट परीक्षणों के साथ संयोजन में), और संकलन समय पर नहीं।

पूर्वगामी कमजोर पड़ने और पोस्टकंडिशन को मजबूत करना

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

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

 class Base { public virtual object Foo(string s) { Contract.Requires(!string.IsNullOrEmpty(s)); Contract.Ensures(Contract.Result<object>() != null); return new object(); } } class Derived : Base { public override object Foo(string s) { // Now we're requiring empty string Contract.Requires(s != null); // And returning only strings Contract.Ensures(Contract.Result<object>() is string); return s; } } 

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

नोट
पोस्टकॉन्डिशन सुदृढीकरण का एक विशिष्ट उदाहरण व्युत्पन्न वर्गों की क्षमता है कि वे अधिक विशिष्ट प्रकार की वापसी कर सकें। इस सुविधा को रिटर्न टाइप कोवरियन कहा जाता है और यह C ++ या Java जैसी भाषाओं में उपलब्ध है। यदि C # ने इस सुविधा का समर्थन किया है, तो Derived.Foo विधि के हस्ताक्षर को बदलना संभव है और एक वस्तु नहीं, बल्कि एक स्ट्रिंग लौटाया जा सकता है। पूर्वधारणाओं को कमजोर करने और पोस्टकंडिशन को मजबूत करने का एक और उदाहरण C # भाषा के 4 वें संस्करण से उपलब्ध प्रतिनिधियों और इंटरफेस का सह-प्रचार और विरोधाभासी है। अनुबंध द्वारा लेख डिजाइन में शर्तों की "कठोरता" के बारे में और पढ़ें । सॉफ्टवेयर की शुद्धता के बारे में , और अनुबंध के बारे में - अनुबंध द्वारा लेख डिजाइन में। विरासत ।

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

पोस्टकंडिशन और इंटरफेसेस

अब आधार कक्षाओं से इंटरफेस पर चलते हैं। पहले खंड में, हमने ICollection इंटरफ़ेस की जांच की, जिसमें से पोस्टकंडिशन संग्रह में तत्वों की संख्या को "कम नहीं" कर रहा था। यह पद बीसीएल से आईसी इंटरफ़ेस ऑफ टी इंटरफ़ेस के अनुबंध के आधार पर प्राप्त किया जाता है। कोड अनुबंध स्थापित करने के बाद, हमारे पास हमारे निपटान में न केवल अपने स्वयं के वर्गों के लिए अनुबंध बनाने की क्षमता है, बल्कि बीसीएल से मानक वर्ग अनुबंध का उपयोग करने की क्षमता भी है।

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

 [ContractClass(typeof(ListContract))] public interface IList : ICollection { } [ContractClassFor(typeof(IList))] internal abstract class ListContract : IList { public void Add(string s) { // Lets create stronger postcondition than ICollection.Add Contract.Ensures(Count == Contract.OldValue(Count) + 1); } //   Count   Contains   } 

असली IList इंटरफ़ेस न केवल पोस्टकंडिशन, बल्कि अन्य दिलचस्प चीजों का एक समूह भी जोड़ता है, लेकिन इस मामले में यह महत्वपूर्ण नहीं है। अब हम एक वर्ग जोड़ते हैं जो IList इंटरफ़ेस को लागू करता है, जो इंटरफ़ेस पोस्टकंडिशन का उल्लंघन करता है:

 public class CustomList : IList { private readonly List<string> _backingList = new List<string>(); public void Add(string s) { // IList postcondition is Count = OldCount + 1, // we're violating it _backingList.Add(s); _backingList.Add(s); } public int Count { get { return _backingList.Count; } } public bool Contains(string s) { return _backingList.Contains(s); } } 

हम स्पष्ट रूप से IList इंटरफ़ेस के ऐड पद्धति के बाद के उल्लंघन का उल्लंघन करते हैं, क्योंकि यह तत्वों की संख्या को एक से नहीं बढ़ाता है, लेकिन तुरंत 2. 2 से। हालांकि, दुखद बात यह है कि न तो स्थैतिक विश्लेषक और न ही यहां तक ​​कि राइटर भी इंटरफेस में पोस्टकंडिशन को मजबूत करने के लिए बिल्कुल भी प्रतिक्रिया नहीं करते हैं। अब, वास्तव में, यह सुविधा कोड अनुबंध पुस्तकालय द्वारा समर्थित नहीं है (इसके अलावा, डेवलपर्स इसे एक विशेषता मानते हैं, बग नहीं, विवरण यहां है )। इसलिए फिलहाल हम आभासी तरीकों की पोस्टकॉन्डिशन को मजबूत कर सकते हैं, हम एक क्लास में पोस्टकॉन्डिशन को मजबूत कर सकते हैं जो कुछ इंटरफ़ेस को लागू करता है, लेकिन हम वारिस इंटरफेस में पोस्टकंडिशन को मजबूत नहीं कर सकते हैं !

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

टी और आईलिस्ट ऑफ टी के संविदा ICollection

यदि आप mscorlib की विधानसभा में सावधानी से खुदाई करते हैं । संविदा। dll , जो कोड कॉन्ट्रैक्ट्स को स्थापित करने के बाद दिखाई देता है, आप विशेष रूप से .NET फ्रेमवर्क के मानक वर्गों के कॉन्ट्रैक्ट और संग्रह के अनुबंधों के बारे में बहुत सारी दिलचस्प चीजें पा सकते हैं। यहाँ T इंटरफ़ेस के T और IList के मुख्य ICollection के अनुबंध हैं:

 // From mscorlib.Contracts.dll [ContractClassFor(typeof(ICollection<>))] internal abstract class ICollectionContract<T> : ICollection<T>, IEnumerable<T>, IEnumerable { public void Add([MarshalAs(UnmanagedType.Error)] T item) { Contract.Ensures(this.Count >= Contract.OldValue<int>(this.Count), "this.Count >= Contract.OldValue(this.Count)"); } public void Clear() { Contract.Ensures(this.Count == 0, "this.Count == 0"); } public int Count { get { int num = 0; Contract.Ensures(Contract.Result<int>() >= 0, "Contract.Result<int>() >= 0"); return num; } } } // From mscorlib.Contracts.dll [ContractClassFor(typeof (IList<>))] internal abstract class IListContract<T> : IList<T>, ICollection<T>, IEnumerable<T>, IEnumerable { void ICollection<T>.Add([MarshalAs(UnmanagedType.Error)] T item) { Contract.Ensures(this.Count == (Contract.OldValue<int>(this.Count) + 1), "Count == Contract.OldValue(Count) + 1"); } public int Count { get { int num = 0; return num; } } } 

नोट
.NET फ्रेमवर्क के विभिन्न संस्करणों के अनुबंध अलग-अलग स्थानों पर स्थित होते हैं, फ्रेमवर्क के 4 वें संस्करण के अनुबंध, उदाहरण के लिए, निम्नलिखित पथ में स्थित हैं: "% PROGRAMS% \ Microsoft \ अनुबंध \ अनुबंध \ .NETFramework \ N.4.0 \"। अनुबंधों वाली विधानसभाओं को इस प्रकार नामित किया गया है: OriginalAssemblyName.Contracts.dll: mscorlib.Contracts.dll, System.Contracts.dll, System.Xml.Contracts.dll।

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

निष्कर्ष

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

संबंधित लिंक

1. GitHub पर अनुबंधAndInheritance प्रोजेक्ट । परीक्षण और टिप्पणियों के साथ इस लेख के सभी उदाहरण शामिल हैं।
   
2. बर्ट्रेंड मेयर। सॉफ्टवेयर सिस्टम का ऑब्जेक्ट ओरिएंटेड डिज़ाइन
   
3. अनुबंध द्वारा डिजाइन। विरासत