अनुबंध और रचनाकारों द्वारा डिजाइन

Question

मैं स्कूल के उद्देश्यों के लिए अपने स्वयं के ऐरेलिस्ट को कार्यान्वित कर रहा हूं, लेकिन चीजों को मसाला देने के लिए मैं सी # 4.0 कोड अनुबंधों का उपयोग करने की कोशिश कर रहा हूं। जब तक मुझे रचनाकारों को अनुबंध जोड़ने की ज़रूरत नहीं थी तब तक सब ठीक थे। क्या मुझे खाली पैरामीटर कन्स्ट्रक्टर में Contract.Ensures() जोड़ना चाहिए?

public ArrayList(int capacity) { 
     Contract.Requires(capacity > 0); 
     Contract.Ensures(Size == capacity); 

     _array = new T[capacity]; 
    } 

    public ArrayList() : this(32) { 
     Contract.Ensures(Size == 32); 
    } 

मैं हाँ कहूंगा, प्रत्येक विधि में एक अच्छी तरह से परिभाषित अनुबंध होना चाहिए। दूसरी तरफ, अगर यह सिर्फ "मुख्य" कन्स्ट्रक्टर को काम सौंप रहा है तो इसे क्यों रखा जाए? तर्कसंगत रूप से, मुझे इसकी आवश्यकता नहीं होगी।

एकमात्र बिंदु मैं देखता हूं कि यह दोनों रचनाकारों में अनुबंध को स्पष्ट रूप से परिभाषित करने के लिए उपयोगी होगा, अगर भविष्य में हमारे पास अनुबंधों के लिए इंटेलिसेंस समर्थन है। क्या ऐसा होगा, यह स्पष्ट होना उपयोगी होगा कि प्रत्येक विधि के कौन से अनुबंध हैं, जैसा कि इंटेलिसेंस में दिखाई देगा।

इसके अलावा, क्या ऐसी कोई किताबें हैं जो अनुबंधों द्वारा डिजाइन के सिद्धांतों और उपयोग पर थोड़ा गहराई से जाती हैं? एक बात यह है कि एक भाषा में अनुबंधों का उपयोग कैसे करें (सी #, इस मामले में) के सिंटैक्स का ज्ञान है, अन्य यह जान रहा है कि इसका उपयोग कैसे और कब किया जाए। मैंने इसके बारे में गहराई लेख में कई ट्यूटोरियल और जॉन स्कीट के सी # को पढ़ा, लेकिन यदि संभव हो तो मैं थोड़ा गहरा जाना चाहूंगा।

धन्यवाद

Answer 1

मैं थॉमस के उत्तर से पूरी तरह से असहमत हूं। जब तक आप ArrayList() के कार्यान्वयन में विकल्प चुन रहे हैं, तब तक आपके पास यह अनुबंध होना चाहिए जो इन विकल्पों को दस्तावेज करता है।

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

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

Answer 2

UMH, मैं पूरी तरह से समझ में नहीं आता क्यों तुम 'सुनिश्चित करता है' भी डिफ़ॉल्ट c'tor में डाल रहा है। क्योंकि यह मुख्य c'tor को कॉल करता है, जो पहले से ही पूर्ण अनुबंध को लागू करता है, डिफ़ॉल्ट c'tor भी परिभाषा के अनुसार करता है। तो यह एक तार्किक अनावश्यकता है, और इसलिए एक बड़ा 'मत करो'। शायद यह व्यावहारिक निहितार्थ हो सकता है, कहते हैं कि जैसे आप - कोड संविदा है कि अच्छा नहीं पता ...

साहित्य के बारे में - सबसे अच्छा स्रोत हैं:

• द्वारा डिजाइन अनुबंध, उदाहरण के द्वारा (पुस्तक, एडिसन -Wesley)
• मुद्दा
• An introduction to Design by Contract (एफिल श्रृंखला पर Wikipedia article, लेकिन डीबीसी सिद्धांतों भाषा-विशिष्ट)

HTH नहीं हैं! थॉमस

Answer 3

क्लाइंट कोड (कोड संविदा का प्रयोग करके) ArrayList का उपयोग करता है पता नहीं होगा कि खाली निर्माता Ensure कि Size == 32 जब तक आप स्पष्ट तो राज्य एक Ensure का उपयोग कर।

तो (उदाहरण के लिए):

var x = new ArrayList(); 
Contract.Assert(x.Size == 32) 

आप चेतावनी दे देंगे "सिद्ध नहीं जोर"।

आपको सभी अनुबंध स्पष्ट रूप से बताए जाने की आवश्यकता है; कोड अनुबंध rewriter/स्थिर चेकर किसी भी निहितार्थ — देख my answer to the related question "Do we have to specify Contract.Requires(…) statements redundantly in delegating methods?"

Answer 4

डिजाइन अनुबंध द्वारा कार्यात्मक प्रोग्रामिंग का गणितीय जड़ों से आता है देखने के लिए एक विधि "के माध्यम से देखने के लिए" नहीं होगा: Preconditions और Postconditions।

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

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

Answer 5

मैं Object Oriented Software Construction, 2nd Edition, या शायद Touch of Class, बर्ट्रेंड मेयर दोनों पढ़ने की अनुशंसा करता हूं। वैकल्पिक रूप से, आप एक ही लेखक से 1992 लेख Applying "Design by Contract" पढ़ सकते हैं।

संक्षेप में:

• वर्ग अपरिवर्तनीय निर्माता (उनमें से किसी को) खत्म करने के बाद पकड़ चाहिए, और पहले और बाद में वर्ग के किसी भी सार्वजनिक विधि निष्पादित किया जाता है।
• विधि पूर्व शर्त और postconditions अतिरिक्त शर्तें जो प्रवेश करने और किसी भी सार्वजनिक विधि बाहर निकलने, अपरिवर्तनीय के साथ पर पकड़ चाहिए।

तो आपके मामले में, इनवेरिएंट पर ध्यान केंद्रित करें। एक सही वस्तु उत्पन्न करें (जो वर्ग आविष्कार को संतुष्ट करता है), इससे कोई फर्क नहीं पड़ता कि कौन सा कन्स्ट्रक्टर लागू किया जाता है।

इस related answer में मैंने एक उदाहरण सहित समान विषयों पर चर्चा की।