Lisk प्रतिस्थापन सिद्धांत और अनुबंध

इस लेख का विचार अलेक्जेंडर बंडी के लेख " एलएसपी के लिए पूरक " से प्रेरित था और इसे अलेक्जेंडर के लेख पर एक विस्तृत टिप्पणी के रूप में माना जा सकता है।

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

अब देखते हैं कि क्या यह .NET प्लेटफ़ॉर्म के साथ मामला है, और आइए इस बारे में बात करते हैं कि क्या हम यह तर्क दे सकते हैं कि यह विधि औपचारिक विनिर्देश के अभाव में इस पद्धति का उल्लंघन करती है कि इस विधि को क्या करना चाहिए।



पहले आपको समस्या की स्थिति के लिए एक छोटा सा संपादन करने की आवश्यकता है (हाँ, मैं समझता हूं कि यह उचित नहीं है, लेकिन इस मामले में यह उचित है)। मूल कार्य ने DoubleList वर्ग द्वारा T इंटरफ़ेस के IList के कार्यान्वयन के बारे में बात की थी, लेकिन वास्तव में, .NET फ्रेमवर्क में, T इंटरफ़ेस के ICollection में Add विधि को घोषित किया गया है, जिसका अर्थ है कि आपको विचार करना चाहिए कि क्या T वर्ग का DoubleList संग्रह अनुबंध का उल्लंघन करता है , सूची का नहीं।

नोट
कोड पढ़ने और उदाहरणों को चलाने में आसानी के लिए, मैं DoubleList वर्ग के एक सामान्यीकृत संस्करण का उपयोग नहीं करूंगा, लेकिन तार संचय के लिए एक विशेष कंटेनर, अर्थात्। वास्तव में, हमारा DoubleList स्ट्रिंग इंटरफ़ेस के ICollection को लागू करेगा।

public class DoubleList : ICollection<string> { private readonly List<string> _backingList = new List<string>(); public void Add(string item) { //     ,   2  _backingList.Add(item); _backingList.Add(item); } //     } 

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

 [Test] public void TestAddMethodAddsOnlyOneElement() { ICollection<string> collection = new DoubleList(); int oldCount = collection.Count; collection.Add("foo"); Assert.That(collection.Count, Is.EqualTo(oldCount + 1)); } 

हां, वास्तव में, यह परीक्षण एक वस्तु के रूप में स्ट्रिंग की संग्रह सूची का उपयोग करते समय ठीक काम करेगा, और यदि DoubleList का उपयोग किया जाता है तो दुर्घटनाग्रस्त हो जाएगा।

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

कुछ अभिव्यक्ति, जैसे x = y / 2 , न तो अपने आप में सही है और न ही गलत है। यह सब इस बात पर निर्भर करता है कि x और y के बीच क्या संबंध होना चाहिए (अधिक जानकारी के लिए, "अनुबंध द्वारा डिजाइन। सॉफ्टवेयर शुद्धता" देखें )। ऐड विधि के साथ स्थिति समान है: इस पद्धति को क्या करना चाहिए, इसका औपचारिक या कम से कम अनौपचारिक विवरण के बिना, हम यह नहीं कह सकते कि क्या यह वारिस द्वारा सही ढंग से लागू किया गया है। अगर हम ICollection (T) .Add Method के लिए आधिकारिक दस्तावेज खोलते हैं, तो हम देखेंगे कि एक पंक्ति है जो कहती है कि यह विधि संग्रह में एक तत्व जोड़ती है। एक ही समय में, बाकी सब कुछ (उदाहरण के लिए, क्या यह वास्तव में या किस मात्रा में जोड़ा जाएगा) सिर्फ हमारी धारणाएं हैं और केवल एक चीज जो आप कर सकते हैं वह यह पता लगाने की कोशिश करें कि टी इंटरफ़ेस के आईसीओलेक्शन के अन्य कार्यान्वयन कैसे व्यवहार करते हैं।

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

 [TestCaseSource("GetAllCollections")] public void TestAddToCollectionTwiceAddsTwoElement(ICollection<string> collection) { int oldCount = collection.Count; if (collection.IsReadOnly) { Console.WriteLine("Current collection type ({0}) is readonly. Skipping it...", collection.GetType()); return; } collection.Add("foo"); collection.Add("foo"); Assert.That(collection.Count, Is.EqualTo(oldCount + 2)); } 

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

 private static ICollection<string>[] GetAllCollections() { return new ICollection<string>[] { new List<string>(), new HashSet<string>(), new Collection<string>(), new BindingList<string>(), new LinkedList<string>(), new ObservableCollection<string>(), new ReadOnlyCollection<string>(new List<string>()), new SortedSet<string>(), new string[]{}, }; } 

अब उपरोक्त परीक्षण चलाएं और देखें कि कम से कम दो प्रकार के संग्रह केवल एक तत्व को जोड़ते हैं, हालांकि हमने दो को जोड़ने के लिए कहा। ये, निश्चित रूप से, संग्रह प्रकार हैं जो डुप्लिकेट को संग्रहीत करने की अनुमति नहीं देते हैं, जैसे टी के हैशसेट और टी के सॉर्टेडसेट ।

अब आइए मूल प्रश्न पर वापस आते हैं: क्या ऐड मेथड के क्रियान्वयन से Lisk प्रतिस्थापन के सिद्धांत में DoubleList वर्ग का उल्लंघन होता है ? उत्तर: नहीं, यह नहीं टूटता!

टी इंटरफ़ेस के ICollection की विधि जोड़ें जोड़ने के बाद संग्रह में कितने तत्व होंगे, इस पर कोई प्रतिबंध नहीं है, जिसका अर्थ है कि हमें उन सभी वर्गों की आवश्यकता नहीं हो सकती है जो एक निश्चित नियम का पालन करने के लिए इस इंटरफ़ेस को लागू करते हैं। वास्तव में, अधिक बेहतर ( टी के ICollection को लागू करने वाले संग्रह के व्यवहार के आधार पर) निम्नलिखित पूर्व शर्त है: ऐड विधि को कॉल करने के बाद, कॉन्टेन्स विधि के लिए अगला कॉल सही लौटना चाहिए और संग्रह में तत्वों की संख्या कम नहीं होनी चाहिए (अर्थात newCount> = oldCount)।

इस मामले में, यदि हमारे परीक्षण में हम मौजूदा बयान को प्रतिस्थापित करते हैं:

 Assert.IsTrue(collection.Contains("foo")); 

तब सभी परीक्षण सफल होंगे।

निष्कर्ष

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

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

-

(*) मैं पाठ में सीधे फुटनोट लिखने के सामान्य नियम से हट जाऊंगा और लिस्कोव के प्रतिस्थापन के सिद्धांत की परिभाषा पर एक अलग उपधारा बनाऊंगा।

प्रतिस्थापन Liskov का सिद्धांत। परिभाषा

जेम्स कोपलेयन की उल्लेखनीय पुस्तक , C ++ प्रोग्रामिंग, Liskov प्रतिस्थापन सिद्धांत की एक उत्कृष्ट और पूरी तरह से समझ से बाहर की परिभाषा प्रदान करती है:

... यदि टाइप S के प्रत्येक ऑब्जेक्ट o1 के लिए T का ऑब्जेक्ट O2 मौजूद है, तो ऐसे सभी प्रोग्रामों के लिए, जिन्हें P के संदर्भ में परिभाषित किया गया है, P का व्यवहार तब नहीं बदलता है जब O1 को O2 से बदल दिया जाता है, तो S, T के लिए आधार प्रकार है।

सामान्य तौर पर, सब कुछ ठीक है, सिवाय इसके कि यह पूरी तरह से स्पष्ट नहीं है कि " टी के संदर्भ में " का मतलब क्या है और यह बिल्कुल स्पष्ट नहीं है कि " पी का व्यवहार नहीं बदलेगा " जब यह व्यवहार कहीं भी वर्णित नहीं है।

एक और लोकप्रिय, लेकिन कोई और अधिक समझने योग्य परिभाषा, बॉब मार्टिन की पुस्तक में पाई जा सकती है:

आधार प्रकार के किसी भी उपप्रकार को प्रतिस्थापित करना संभव होना चाहिए ।

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

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

संबंधित लिंक

1. बर्ट्रेंड मेयर। सॉफ्टवेयर सिस्टम का ऑब्जेक्ट ओरिएंटेड डिज़ाइन
   
2. रॉबर्ट सी। मार्टिन। C # में चुस्त विकास के सिद्धांत, पैटर्न और तकनीक
   
3. रॉबर्ट सी। मार्टिन द लिस्कोव प्रतिस्थापन सिद्धांत
   
4. रॉबर्ट सी। मार्टिन डिजाइन सिद्धांत और पैटर्न
   
5. अनुबंध द्वारा डिजाइन। सॉफ्टवेयर शुद्धता के बारे में
   
6. अनुबंध द्वारा डिजाइन। विरासत