क्या DRY अच्छी है या यह SOL से O तोड़ सकता है

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

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

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

हमारे पास एक पार्सल वर्ग है जो बताता है कि एक नियमित पैकेज कैसे काम करता है:

public interface IParcel { string Barcode {get; set;} } public class Parcel: IParcel { public string Barcode {get; set;} } 

यह केवल पुराने पार्सल वर्ग और IParcel इंटरफ़ेस दोनों के लिए एक क्षेत्र जोड़ने के लिए बहुत ही आकर्षक है:

 public interface IParcel { string Barcode {get; set;} bool IsUrgent {get; set;} } public class Parcel: IParcel { public string Barcode {get; set;} public bool IsUrgent {get; set;} } 

हालाँकि, ऐसे कोड को CodeReview पास नहीं करना चाहिए! एक सख्त और अनुभवी कोड चेकर को टिप्पणी के साथ इसे वापस करना चाहिए: "इस तरह का कार्यान्वयन ओपन-बंद सिद्धांत का उल्लंघन करता है।"

एक नया UrgentParcel वर्ग बनाना बेहतर है, और आपको इंटरफ़ेस या पार्सल वर्ग बदलने की आवश्यकता नहीं होगी। क्लास और इंटरफ़ेस फ़ाइलें अछूती रहेंगी:

 public class UrgentParcel: IParcel { public string Barcode {get; set;} } 

यह ओपन-क्लोज्ड सिद्धांत का पालन होगा, और इस तरह के कोड को CodeReview के साथ टिप्पणियां प्राप्त नहीं होंगी।

अब डीआरवाई पर वापस आते हैं और जिस तरह से ओपन-क्लोज्ड सिद्धांत को लागू करना मुश्किल हो जाता है।

कल्पना कीजिए कि पार्सल वर्ग में हमारे पास "स्थिति की स्थिति" फ़ील्ड है और इस स्थिति को बदलने के लिए कुछ तर्क:

 public class Parcel: IParcel { public string Barcode {get; set;} //   ( ,     ..) public ParcelStatuses Status {get; } // ,      "" public void ArrivedToRecipient(){ this.Status = ParcelStatuses.Arrived; } } 

क्या इस तर्क को UrgentParcel वर्ग में कॉपी करने की आवश्यकता है? DRY सिद्धांत कहता है कि किसी भी तरह से नहीं। यह बहुत बेहतर है कि UrgentParcel वर्ग केवल Parcel वर्ग से विरासत में मिला है, जो समस्या का हल करता है और UrgentPoRecipient पद्धति के शरीर को UrgentParcel वर्ग में कॉपी / पेस्ट नहीं करना पड़ता है।

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

आमतौर पर, DRY के पक्ष में एक मुख्य तर्क यह तथ्य है कि यदि ArrivedToRecipient पद्धति में कोई त्रुटि पाई जाती है, तो उसे जहाँ भी कॉपी किया गया है, उसे ठीक किया जाना चाहिए। तो यह सिर्फ करने की जरूरत नहीं है। यदि नियमित पैकेज के साथ काम करते समय ArrivedToRecipient पद्धति में कोई त्रुटि पाई जाती है, तो साधारण पैकेज के काम को सही करना आवश्यक है। लेकिन किसी ने तत्काल पार्सल के काम के बारे में शिकायत नहीं की और, शायद, हर कोई खुश है कि कैसे तत्काल पार्सल काम करते हैं।

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

यहाँ इस तरह की टिप्पणी का एक उदाहरण है:

 public class Parcel: IParcel{ ... /// <summary> ///    "" /// </summary> /// <remarks>NOTE:     : <see cref="UrgentParcel"/></remarks> public void ArrivedToRecipient(){ ... } } public class UrgentParcel: IParcel{ ... /// <summary> ///    "" /// </summary> /// <remarks>NOTE:      : <see cref="Parcel"/></remarks> public void ArrivedToRecipient(){ ... } } 

इस मुद्दे पर समुदाय की राय बहुत दिलचस्प है। आपकी टिप्पणियों के लिए अग्रिम धन्यवाद।