कोड गंध: स्वचालित गुण

यह पोका-योक डिज़ाइन के बारे में एक श्रृंखला की तीसरी पोस्ट है - जिसे एनकैप्सुलेशन के रूप में भी जाना जाता है।

स्वचालित गुण C # में सबसे बेमानी विशेषताओं में से एक हैं। मुझे पता है कि बहुत से लोग उन्हें बहुत प्यार करते हैं, लेकिन वे एक समस्या को हल करते हैं जो आपको मुठभेड़ नहीं करना चाहिए।

मैं इस बात से बिलकुल सहमत हूँ कि ऐसा दिखने वाला कोड पूरी तरह से बेमानी है:

private string name; public string Name { get { return this.name; } set { this.name = value; } } 

हालाँकि, समस्या का हल इस कोड को फिर से लिखना नहीं है:

 public string Name { get; set; } 

पहले उदाहरण में कोड के साथ समस्या इसकी औपचारिकता नहीं है। समस्या यह है कि यह एनकैप्सुलेशन को तोड़ता है। वास्तव में

"[...] गेटर्स और सेटर्स इनकैप्सुलेशन या छुपा जानकारी प्रदान नहीं करते हैं: वे इन सिद्धांतों का उल्लंघन करने का एक तरीका है, जो प्रोग्रामिंग भाषा द्वारा वैध है।"
जेम्स ओ। कोपलियन और गर्ट्रुड बोजर्नविग। झुक वास्तुकला। विले। 2010. पी। 134।

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

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

 private string name; public string Name { get { return this.name; } set { if (value == null) { throw new ArgumentNullException("value"); } this.name = value; } } 

वैकल्पिक रूप से, गार्ड अभिव्यक्ति भी अशक्त के लिए जाँच कर सकता है और एक डिफ़ॉल्ट मूल्य प्रदान कर सकता है:

 private string name; public string Name { get { return this.name; } set { if (value == null) { this.name = ""; return; } this.name = value; } } 

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

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

 public int RetryCount { get; set; } 

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

 private int retryCount; public int RetryCount { get { return this.retryCount; } set { if (value < 0) { throw new ArgumentOutOfRangeException(); } this.retryCount = value; } } 

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

संशोधित डिजाइन: सुरक्षात्मक अभिव्यक्ति
जैसा कि मैंने पहले बताया, एक स्वचालित संपत्ति के साथ एक समस्या को ठीक करने का सबसे तेज़ तरीका एक संपत्ति को एक सुरक्षात्मक अभिव्यक्ति के साथ लागू करना है। यह सुनिश्चित करता है कि वर्ग के आक्रमणकारियों को ठीक से समझाया गया है।

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

 public int Temperature { get; set; } 

यह कई कारणों से खराब डिज़ाइन है। यह माप की इकाई के अर्थ से संबंधित नहीं है और असीमित मूल्यों के असाइनमेंट की अनुमति देता है। क्या होता है अगर -100 सौंपा जाता है? यदि इकाई सेल्सियस है, तो सब कुछ ठीक है, लेकिन यदि यह केल्विन है, तो एक गलती है। यूनिट के बावजूद, int.inValue असाइन करने का प्रयास विफल होना चाहिए।
एक नए प्रकार के तापमान को शुरू करने और दर्ज की गई संपत्ति के प्रकार को बदलकर एक अधिक टिकाऊ डिजाइन प्राप्त किया जा सकता है। आक्रमणकारियों को बचाने के अलावा, नया वर्ग विभिन्न तापमान उपायों के बीच रूपांतरण को भी बाधित कर सकता है।
हालाँकि, यदि मान ऑब्जेक्ट को संदर्भ प्रकार के रूप में लागू किया जाता है, तो स्थिति ऊपर वर्णित स्थिति के बराबर हो जाती है और अशक्त के लिए जाँच आवश्यक है। यदि मान ऑब्जेक्ट को मूल्य प्रकार के रूप में लागू किया जाता है, तो स्वचालित गुणों का उपयोग उचित है।
निष्कर्ष: स्वचालित गुण शायद ही कभी उपयुक्त होते हैं। वास्तव में, वे केवल तभी मान्य होते हैं जब संपत्ति प्रकार एक मूल्य प्रकार होता है और सभी संभावित मूल्य मान्य होते हैं। चूँकि ऐसे कई मामले हैं जहाँ स्वत: संपत्तियाँ उपयुक्त हैं, इसलिए उनके उपयोग को पूरी तरह से खारिज नहीं किया जा सकता है, लेकिन उनका उपयोग करने की आवश्यकता को आगे की जाँच के लिए एक कारण माना जाना चाहिए। स्वचालित गुणों का उपयोग कोड में एक "गंध" है, लेकिन एक विरोधी पैटर्न नहीं है।
यह ध्यान देने योग्य है कि संपत्तियां डेमेटर के कानून का भी उल्लंघन कर सकती हैं, लेकिन यह भविष्य के पोस्ट के लिए एक विषय है।