आप DRY सिद्धांत को तोड़ रहे होंगे, जिसमें हर जगह एक ज़िप कोड का उपयोग किया जाता है।
दूसरी ओर, जब कई अलग-अलग देशों और उनके अलग-अलग ज़िपकोड सिस्टम से निपटते हैं, तो इसका मतलब है कि आप एक ज़िपकोड को मान्य नहीं कर सकते हैं जब तक कि आप देश को सवाल में नहीं जानते हैं। तो आपकाZipCode कक्षा को देश को भी संग्रहीत करने की आवश्यकता है।
लेकिन क्या आप फिर से दोनों Address(जो कि zipcode का भी हिस्सा है), और zipcode (सत्यापन के लिए) के हिस्से के रूप में देश को अलग से स्टोर करते हैं ?
- यदि आप करते हैं, तो आप DRY का भी उल्लंघन कर रहे हैं। यहां तक कि अगर आप इसे DRY उल्लंघन नहीं कहते हैं (क्योंकि प्रत्येक उदाहरण एक अलग उद्देश्य प्रदान करता है), यह अभी भी अनावश्यक रूप से अतिरिक्त मेमोरी ले रहा है, दो देश के मूल्यों के अलग होने पर दरवाजे को खोलने के शीर्ष पर (जो उन्हें तार्किक रूप से कभी नहीं करना चाहिए हो)।
- या, वैकल्पिक रूप से, यह आपको यह सुनिश्चित करने के लिए दो डेटा बिंदुओं को सिंक्रनाइज़ करने की आवश्यकता है कि वे हमेशा समान हैं, जो बताता है कि आपको वास्तव में इस डेटा को किसी भी बिंदु पर संग्रहीत करना चाहिए, इस प्रकार उद्देश्य को पराजित करना।
- यदि आप नहीं करते हैं, तो यह एक
ZipCodeवर्ग नहीं है Address, बल्कि एक वर्ग है, जिसमें फिर से एक string ZipCodeअर्थ होगा जिसमें हम पूर्ण चक्र में आए हैं।
उदाहरण के लिए, मैं एक व्यापार कोड के बारे में पोस्ट कोड के बारे में एक स्ट्रिंग के बजाय एक पोस्ट कोड से बात कर सकता हूं।
लाभ यह है कि आप डोमेन मॉडल का वर्णन करते समय उनके बारे में बात कर सकते हैं।
मैं आपके अंतर्निहित दावे को नहीं समझता कि जब जानकारी के एक टुकड़े में एक परिवर्तनशील प्रकार होता है, तो आप किसी भी तरह से उस प्रकार का उल्लेख करने के लिए बाध्य होते हैं जब भी आप किसी व्यापार विश्लेषक से बात कर रहे हों।
क्यूं कर?आप केवल "ज़िपकोड" के बारे में बात करने में असमर्थ क्यों हैं और विशिष्ट प्रकार को पूरी तरह से छोड़ देते हैं? आप अपने व्यवसाय के साथ किस तरह की चर्चा कर रहे हैं (तकनीकी नहीं!) विश्लेषक जहां संपत्ति का प्रकार बातचीत के लिए उपयुक्त है?
मैं कहाँ से हूँ, पोस्टकोड हमेशा संख्यात्मक होते हैं। इसलिए हमारे पास एक विकल्प है, हम इसे एक intया एक के रूप में संग्रहीत कर सकते हैं string। हम एक स्ट्रिंग का उपयोग करते हैं क्योंकि डेटा पर गणितीय कार्यों की कोई अपेक्षा नहीं है, लेकिन कभी भी एक व्यापार विश्लेषक ने मुझे नहीं बताया कि इसे एक स्ट्रिंग होने की आवश्यकता है। यह निर्णय डेवलपर (या यकीनन तकनीकी विश्लेषक को छोड़ दिया जाता है, हालांकि मेरे अनुभव में वे सीधे किरकिरा नहीं करते हैं)।
एक व्यावसायिक विश्लेषक डेटा प्रकार के बारे में परवाह नहीं करता है, जब तक कि एप्लिकेशन वह करता है जो वह करने की उम्मीद करता है।
वैधता एक मुश्किल से निपटने के लिए एक मुश्किल जानवर है, क्योंकि यह मनुष्यों की अपेक्षा पर निर्भर करता है।
एक के लिए, मैं सत्यापन तर्क से सहमत नहीं हूं कि यह दिखाने के लिए कि आदिम जुनून से क्यों बचा जाना चाहिए, क्योंकि मैं इस बात से सहमत नहीं हूं (एक सार्वभौमिक सत्य के रूप में) डेटा को हमेशा हर समय मान्य करने की आवश्यकता होती है।
उदाहरण के लिए, क्या होगा यदि यह अधिक जटिल लुकअप है? एक साधारण प्रारूप जांच के बजाय, यदि आपकी मान्यता बाहरी एपीआई से संपर्क करने और प्रतिक्रिया की प्रतीक्षा करने पर मजबूर करती है तो क्या होगा? क्या आप वास्तव में अपने एप्लिकेशन को हर उस ZipCodeवस्तु के लिए इस बाहरी एपीआई को कॉल करने के लिए मजबूर करना चाहते हैं जो आप तुरंत चाहते हैं?
शायद यह एक सख्त व्यावसायिक आवश्यकता है, और फिर यह बिल्कुल उचित है। लेकिन यह एक सार्वभौमिक सत्य नहीं है। उपयोग के बहुत सारे मामले होंगे जहां यह एक समाधान की तुलना में अधिक बोझ है।
दूसरे उदाहरण के रूप में, अपने पते को एक फॉर्म में दर्ज करते समय, अपने देश से पहले अपना पिनकोड दर्ज करना आम है। जबकि UI में तत्काल सत्यापन प्रतिक्रिया होना अच्छा है, यह वास्तव में मेरे लिए एक बाधा होगी (एक उपयोगकर्ता के रूप में) यदि एप्लिकेशन ने मुझे "गलत" ज़िपकोड प्रारूप के लिए सचेत किया, क्योंकि मुद्दे का वास्तविक स्रोत है (जैसे) कि मेरा देश वह देश नहीं है जिसे डिफ़ॉल्ट रूप से चुना गया है, और इस प्रकार सत्यापन गलत देश के लिए हुआ है।
यह गलत त्रुटि संदेश है, जो उपयोगकर्ता को विचलित करता है और अनावश्यक भ्रम का कारण बनता है।
ठीक उसी तरह जैसे कि सदा का सत्यापन एक सार्वभौमिक सत्य नहीं है, न ही मेरे उदाहरण हैं। यह प्रासंगिक है । कुछ एप्लिकेशन डोमेन को बाकी सभी के ऊपर डेटा सत्यापन की आवश्यकता होती है। अन्य डोमेन कोई प्राथमिकता नहीं देते हैं जो प्राथमिकताओं की सूची में उच्च होती हैं क्योंकि इससे होने वाली परेशानी उनकी वास्तविक प्राथमिकताओं (जैसे उपयोगकर्ता अनुभव, या शुरू में दोषपूर्ण डेटा संग्रहीत करने की क्षमता के साथ संघर्ष करती है, इसलिए इसे कभी भी अनुमति नहीं दी जा सकती है। संग्रहीत)
जन्म तिथि: जाँच करें कि मन से अधिक और आज की तारीख से कम है।
वेतन: जाँच करें कि शून्य से अधिक या उसके बराबर है।
इन मान्यताओं के साथ समस्या यह है कि वे अधूरे, निरर्थक या बहुत बड़ी समस्या के सूचक हैं ।
यह जाँचना कि एक तिथि मन से अधिक निरर्थक है। माइंडेट का शाब्दिक अर्थ है कि यह सबसे छोटी संभावित तिथि है। इसके अलावा, आप प्रासंगिकता की रेखा कहां खींचते हैं? रोकने की DateTime.MinDateअनुमति देने में क्या बात है DateTime.MinDate.AddSeconds(1)? आप एक विशेष मूल्य को संजो रहे हैं जो कई अन्य मूल्यों की तुलना में विशेष रूप से गलत नहीं है।
मेरा जन्मदिन १ ९ birthday it है (यह नहीं है, लेकिन मान लेते हैं कि यह है)। लेकिन मान लें कि आपके एप्लिकेशन का डेटा गलत है, और इसके बजाय यह कहता है कि मेरा जन्मदिन है:
- 1 जनवरी 1978
- जनवरी १ Jan२२
- जनवरी १३५५
ये सभी तारीखें गलत हैं। उनमें से कोई भी दूसरे की तुलना में "अधिक सही" नहीं है। लेकिन आपका सत्यापन नियम केवल इन तीन उदाहरणों में से एक को पकड़ेगा ।
आपने इस डेटा का उपयोग कैसे कर रहे हैं, इस संदर्भ को भी पूरी तरह से छोड़ दिया है। अगर यह एक जन्मदिन अनुस्मारक बॉट में उदाहरण के लिए उपयोग किया जाता है, तो मैं कहूंगा कि सत्यापन व्यर्थ है क्योंकि गलत तारीख भरने के लिए कोई विशेष बुरा परिणाम नहीं है।
दूसरी ओर, यदि यह सरकारी डेटा है और आपको किसी की पहचान को प्रमाणित करने के लिए जन्मतिथि की आवश्यकता है (और ऐसा करने में विफलता बुरे परिणामों की ओर ले जाती है, जैसे कि किसी सामाजिक सुरक्षा से इनकार करना), तो डेटा की शुद्धता सर्वोपरि है और आपको पूरी तरह से इसकी आवश्यकता है डेटा को मान्य करें। अब आपके पास प्रस्तावित सत्यापन पर्याप्त नहीं है।
वेतन के लिए, इसमें कुछ सामान्य ज्ञान है जो नकारात्मक नहीं हो सकता। लेकिन अगर आप वास्तविक रूप से उम्मीद करते हैं कि निरर्थक डेटा दर्ज किया जा रहा है, तो मेरा सुझाव है कि आप इस निरर्थक डेटा के स्रोत की जांच करें। क्योंकि अगर उन्हें कामुक डेटा दर्ज करने के लिए भरोसा नहीं किया जा सकता है, तो आप उन्हें सही डेटा दर्ज करने के लिए भी भरोसा नहीं कर सकते हैं ।
यदि इसके बजाय आपके आवेदन से वेतन की गणना की जाती है, और किसी तरह यह नकारात्मक (और सही) संख्या के साथ समाप्त होना संभव है, तो एक बेहतर तरीका यह होगा Math.Max(myValue, 0)कि सत्यापन को विफल करने के बजाय नकारात्मक संख्याओं को 0 में बदल दें। क्योंकि यदि आपके तर्क ने निर्णय लिया कि परिणाम एक नकारात्मक संख्या है, तो सत्यापन को विफल करने का मतलब है कि इसे गणना को फिर से करना होगा, और यह सोचने का कोई कारण नहीं है कि यह दूसरी बार एक अलग संख्या के साथ आएगा।
और अगर यह एक अलग संख्या के साथ आता है, तो फिर से आपको संदेह करने की ओर ले जाता है कि गणना सुसंगत नहीं है और इसलिए उस पर भरोसा नहीं किया जा सकता है।
यह कहना नहीं है कि सत्यापन उपयोगी नहीं है। लेकिन निरर्थक मान्यता खराब है, क्योंकि यह वास्तव में एक समस्या का समाधान नहीं है, और लोगों को सुरक्षा की झूठी भावना प्रदान करते हुए प्रयास करता है।