डेटा सत्यापन में क्या गलत है और लिस्कोव प्रतिस्थापन सिद्धांत का इससे क्या लेना-देना है?

यदि आप कभी-कभी अपने आप से सवाल पूछते हैं: "इस विधि में मेरे लिए सब कुछ अच्छा है?" और "क्या होता है अगर यह ठीक है" और "सिर्फ मामले में जांच करना बेहतर है" के बीच चयन करें, तो आपका स्वागत है ...

सुधार: जैसा कि lorc और 0xd34df00d ने उल्लेख किया है , नीचे जो चर्चा की गई है, उसे निर्भर प्रकार कहा जाता है। आप उनके बारे में यहां पढ़ सकते हैं। खैर, नीचे इस पर मेरे विचारों के साथ स्रोत पाठ है।

विकास के दौरान, अक्सर कुछ एल्गोरिथ्म के लिए डेटा की वैधता को सत्यापित करने की आवश्यकता होती है। औपचारिक रूप से, इसे निम्नानुसार वर्णित किया जा सकता है: मान लें कि हमें एक निश्चित डेटा संरचना मिलती है, एक निश्चित सीमा (ओडीजेड) की एक निश्चित सीमा के अनुपालन के लिए इसके मूल्य की जांच करें, और इसे पास करें। इसके बाद, एक ही डेटा संरचना को एक ही सत्यापन के अधीन किया जा सकता है। यदि संरचना अपरिवर्तित रहती है, तो इसकी वैधता को फिर से जाँचना स्पष्ट रूप से एक अनावश्यक कार्रवाई है।

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

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

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

class Parent { ... } class Child : Parent { ... } ... void processValidObject(Parent parent) { if (parent is Child) { // process } else { // error } } 

सहमत हूँ कि अब समस्या बहुत स्पष्ट है। हमसे पहले Liskov प्रतिस्थापन सिद्धांत का एक विहित उल्लंघन है। पढ़ें कि प्रतिस्थापन के सिद्धांत का उल्लंघन करना बुरा क्यों है, उदाहरण के लिए, यहां ।

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

स्विफ्ट में, सिंटैक्स स्तर पर, नल की जांच की समस्या हल हो जाती है। विचार को अशक्त और अशक्त प्रकारों में अलग करना है। इसी समय, यह चीनी के रूप में इस तरह से बनाया जाता है कि प्रोग्रामर को एक नए प्रकार की घोषणा करने की आवश्यकता नहीं है। एक चर प्रकार की घोषणा करते समय, ClassName गारंटी देता है कि चर nonzero है, और ClassName घोषित करते समय? चर शून्य है। एक ही समय में, कोवरियनस प्रकारों के बीच मौजूद होता है, अर्थात, आप क्लासनेम के उन तरीकों को पास कर सकते हैं, जो एनकेनेम को स्वीकार करते हैं?

इस विचार को उपयोगकर्ता-परिभाषित डीएलडी तक विस्तारित किया जा सकता है। प्रकार में संग्रहीत डीएलएड युक्त मेटाडेटा के साथ वस्तुओं को प्रदान करना ऊपर वर्णित समस्याओं को समाप्त कर देगा। किसी भाषा में इस तरह के उपकरण के लिए समर्थन प्राप्त करना अच्छा होगा, लेकिन यह व्यवहार "साधारण" OO भाषाओं में भी लागू किया जाता है, जैसे कि Java या C #, विरासत और एक कारखाने का उपयोग करके।

डेटा सत्यापन के साथ स्थिति एक और पुष्टि है कि ओओपी में इकाइयां वास्तविक दुनिया से नहीं ली जाती हैं, लेकिन इंजीनियरिंग की जरूरतों से।

यूपीडी: जैसा कि टिप्पणियों में सही ढंग से उल्लेख किया गया है, यह तभी उप योग बनाता है जब हमें अतिरिक्त विश्वसनीयता मिलती है और समान मान्यताओं की संख्या कम होती है।

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