डिजाइन गंध: निरर्थक आवश्यक विशेषता

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

हाल ही में, मैंने कुछ Microsoft प्रौद्योगिकी घटना से एक उत्साही पोस्ट पढ़ी:

कोड में [आवश्यक] विशेषता स्वचालित रूप से डेटाबेस में एक रिकॉर्ड बनाती है जो अशक्त नहीं मान सकता है, और वेब पेज पर सत्यापन भी बनाता है - simpotically [...]

मैंने कल्पना की कि यह कुछ इस तरह दिख सकता है:

public class Smell { [Required] public int Id { get; set; } } 

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

संशोधित डिजाइन
[आवश्यक] विशेषता निरर्थक है क्योंकि यह घोषित करने का एक बेहतर तरीका है कि डेटा का एक टुकड़ा आवश्यक है। यह .NET 1.0 से संभव हुआ है। यहाँ एक ही घोषणा का पोका-योक संस्करण है:

 public class Fragrance { private readonly int id; public Fragrance(int id) { this.id = id; } public int Id { get { return this.id; } } } 

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

अनुवादक से: अनुवाद के रूप में पोस्ट प्रकाशित करना भूल गया। मूल के लेखक मार्क सीमन हैं। मूल से लिंक करें।