एपीआई अनुरोध / प्रतिक्रिया में खाली स्ट्रिंग, अशक्त या खाली संपत्ति का उपयोग करें

Question

जब एक एपीआई के माध्यम से ऑब्जेक्ट को स्थानांतरित किया जाता है, तो स्कीमालेस जेएसएन प्रारूप में, गैर-मौजूद स्ट्रिंग संपत्ति को वापस करने का आदर्श तरीका क्या है? मुझे पता है कि नीचे सूचीबद्ध सूचियों में उदाहरण के रूप में ऐसा करने के विभिन्न तरीके हैं।

• अशक्त से बचें
• वापसी शून्य
• खाली संपत्ति निकालें

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

एक कोड बिंदु से, केवल एक प्रकार के साथ काम करने के लिए स्ट्रिंग कार्यों को प्रतिबंधित करना, अर्थात string(शून्य नहीं), उन्हें साबित करना आसान बनाता है; अशक्त होने से बचना भी Optionवस्तु होने का एक कारण है । इसलिए, यदि कोड जो अनुरोध / प्रतिक्रिया उत्पन्न करता है, वह शून्य का उपयोग नहीं करता है, तो मेरा अनुमान है कि एपीआई के दूसरी तरफ कोड भी शून्य का उपयोग करने के लिए मजबूर नहीं होगा।

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

तो, ऐसा करने का सबसे अच्छा तरीका क्या है जो उन चिंताओं को संबोधित करता है? क्या यह वस्तु के प्रारूप पर हस्तांतरित (स्कीमा / स्कीमालेस) पर निर्भर करता है?

Comments

यह भी ध्यान दें कि ओरेकल खाली तार और अशक्त तार को उसी तरह व्यवहार करता है। और सही हैं: एक पेपर प्रश्नावली पर, आप बिना दिए गए उत्तर और एक रिक्त स्ट्रिंग से मिलकर उत्तर के बीच अंतर कैसे कर सकते हैं?

— बर्नहार्ड हिलर

यदि आप इनहेरिटेंस का उपयोग करते हैं if( value === null) { use parent value; } , तो यह कहना आसान है हालांकि, यदि आप बच्चे का मान सेट करते हैं, यहां तक ​​कि एक खाली स्ट्रिंग (जैसे रिक्त के साथ डिफ़ॉल्ट पैरेंट वैल्यू को ओवरराइड करते हैं), तो आप मूल्य को "री-इनहेरिट" कैसे करते हैं? मेरे लिए, इसे शून्य के रूप में स्थापित करने का अर्थ होगा "इस मूल्य को अनसुना करना ताकि हम मूल मूल्य का उपयोग करना जानते हैं।"

— फ्रैंक फोर्ट

चूँकि "खाली संपत्ति को हटाओ" भी इसीलिए "ए" से बचना है null(यह सत्य है कि nullइस तरह से परहेज किया जाता है), प्रश्नकर्ता का अर्थ है "गैर-अशक्त लौटें" [वस्तु] (यानी: खाली स्ट्रिंग, खाली एरे, आदि) जब वे "से बचें" लिखें।

— cellepo

Answer 1

TLDR; अशक्त गुणों को दूर करें

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

जब आप JSON को सिर्फ एक ट्रांसमिशन प्रारूप के रूप में देखते हैं, तो यह उन गुणों को छोड़ देता है जो सेट नहीं होते हैं। तार भर भेजना कम है। यदि आपकी बैक-एंड भाषा डिफ़ॉल्ट रूप से nulls का उपयोग नहीं करती है, तो आप संभवतः त्रुटि देने के लिए अपने deserializer को कॉन्फ़िगर कर सकते हैं। उदाहरण के लिए, Newtonsoft.Json के लिए मेरा सामान्य सेटअप optionकेवल F # प्रकारों से / के लिए अशक्त / अनुपलब्ध गुणों का अनुवाद करता है और अन्यथा त्रुटि होगी। यह एक प्राकृतिक प्रतिनिधित्व देता है कि कौन से क्षेत्र वैकल्पिक हैं ( optionप्रकार के साथ )।

हमेशा की तरह, सामान्यीकरण केवल आपको अभी तक मिलता है। शायद ऐसे मामले हैं जहां एक डिफ़ॉल्ट या अशक्त संपत्ति बेहतर फिट होती है। लेकिन कुंजी आपके सिस्टम के किनारे पर डेटा संरचनाओं को व्यावसायिक वस्तुओं के रूप में देखने के लिए नहीं है। व्यावसायिक वस्तुओं को सफलतापूर्वक बनाए जाने पर व्यावसायिक गारंटी (उदाहरण के लिए कम से कम 3 वर्ण) होनी चाहिए। लेकिन तार से खींची गई डेटा संरचनाओं की कोई वास्तविक गारंटी नहीं है।

Comments

जबकि सबसे आधुनिक serializers वैकल्पिक फ़ील्ड है, प्रतिक्रिया से nulls को छोड़ते हुए है नहीं , क्योंकि यह नल क्षेत्रों को संभालने के लिए अतिरिक्त जटिलता उत्पन्न हो जाएं हमेशा एक अच्छा विचार,। इस प्रकार, यह वास्तव में केस-डिपेंडेंट है, यह इस बात पर निर्भर करता है कि आपकी क्रमबद्धता लाइब्रेरी nullables को कैसे संभालती है, और उन nullables को संभालने की अतिरिक्त (संभावित) अतिरिक्त जटिलता वास्तव में प्रति अनुरोध कुछ बाइट्स को सहेजने के लायक है या नहीं । आपको अपने व्यावसायिक मामलों का विश्लेषण करने के लिए कड़ी मेहनत करनी चाहिए।

— क्रिस क्रेफ़िस

@ क्रिसहाइरफाइस हां, मेरा मानना ​​है कि अंतिम पैराग्राफ में यह शामिल है। ऐसे मामले हैं जहां विभिन्न रणनीतियों को नियोजित करना बेहतर होगा।

— कासे स्पीकमैन

मैं सहमत हूं कि JSON का उपयोग केवल ट्रांसमिशन प्रारूप के रूप में किया जाता है, यह CORBA जैसे तारों के माध्यम से ऑब्जेक्ट पास नहीं कर रहा है। मैं यह भी मानता हूं कि गुणों को जोड़ा और हटाया जा सकता है; अभ्यावेदन बदल सकते हैं, नियंत्रण बदल सकते हैं, विशेष रूप से वेब पर।

— imel96

Answer 2

अद्यतन: मैंने उत्तर को थोड़ा संपादित किया है, क्योंकि इससे भ्रम पैदा हो सकता है।

---

खाली स्ट्रिंग के साथ जाना एक निश्चित संख्या है। खाली स्ट्रिंग अभी भी एक मूल्य है, यह सिर्फ खाली है। कोई मूल्य, एक निर्माण जो कुछ भी प्रतिनिधित्व करता है का उपयोग करते हुए उल्लेख किया जाना चाहिए null।

एपीआई डेवलपर के दृष्टिकोण से, केवल दो प्रकार के गुण मौजूद हैं:

• आवश्यक (ये जरूरी है कि उनके विशिष्ट प्रकार का मूल्य हो और जरूरी नहीं कि वे खाली हों),
• वैकल्पिक (इन MAY में उनके विशिष्ट प्रकार का मान होता है लेकिन MAY में भी होता है null।

इससे यह स्पष्ट हो जाता है कि जब कोई संपत्ति अनिवार्य है, अर्थात। आवश्यकता है, यह कभी नहीं हो सकता null।

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

गतिशील रूप से ग्राहकों पर अतिरिक्त स्थितियों सहित प्रतिक्रिया बलों से क्षेत्रों को हटाने / हटाने।

---

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

Comments

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

— imel96

@ imel96 गैर-वैकल्पिक फ़ील्ड कभी भी अशक्त नहीं हो सकते। यदि कुछ गैर-वैकल्पिक है तो उसे हमेशा एक मान होना चाहिए (उसके विशिष्ट प्रकार का)।

— एंडी

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

— jleach

@DavidPacker तो, अगर मैं सही ढंग से समझता हूं, तो आप nullमूल्य वैकल्पिक है इंगित करने के लिए उपयोग करते हैं । इसलिए, जब आप एक ऐसी वस्तु को परिभाषित करते हैं, जिसमें गैर-वैकल्पिक स्ट्रिंग संपत्ति होती है, और उपभोक्ता के पास यह संपत्ति नहीं होती है, तो उसे उस संपत्ति के लिए खाली स्ट्रिंग भेजनी होगी। क्या वह सही है?

— imel96

@GregoryNisbet ऐसा मत करो, कृपया। इसका कोई अर्थ नही बन रहा है।

— एंडी

Answer 3

null उपयोग अनुप्रयोग / भाषा निर्भर है

अंततः nullएक वैध आवेदन मूल्य के रूप में उपयोग करने या न करने का विकल्प काफी हद तक आपके आवेदन और प्रोग्रामिंग भाषा / इंटरफ़ेस / किनारे से निर्धारित होता है।

मूलभूत स्तर पर, मैं विभिन्न प्रकारों का उपयोग करने की कोशिश करूँगा यदि मूल्यों के अलग-अलग वर्ग हैं। nullएक विकल्प हो सकता है यदि आपका इंटरफ़ेस इसे अनुमति देता है और आपके द्वारा प्रतिनिधित्व करने की कोशिश कर रही संपत्ति के केवल दो वर्ग हैं। यदि आपका इंटरफ़ेस या प्रारूप इसे अनुमति देता है, तो संपत्ति को स्वीकार करना एक विकल्प हो सकता है। एक नया कुल प्रकार (वर्ग, वस्तु, संदेश प्रकार) एक और विकल्प हो सकता है।

आपके स्ट्रिंग उदाहरण के लिए, यदि यह प्रोग्रामिंग भाषा में है, तो मैं अपने आप से कुछ सवाल पूछूंगा।

1. क्या मैं भविष्य के प्रकारों को जोड़ने की योजना बना रहा हूं? यदि हां, तो Optionआपके इंटरफेस डिजाइन के लिए एक बेहतर होगा।
2. मुझे उपभोक्ताओं के कॉल को मान्य करने की आवश्यकता है? स्थिर? गतिशील रूप से? इससे पहले? बाद? बिलकुल? यदि आपकी प्रोग्रामिंग भाषा इसका समर्थन करती है, तो स्थिर टाइपिंग के लाभों का उपयोग करें क्योंकि यह आपके द्वारा सत्यापन के लिए बनाई गई कोड की मात्रा से बचता है। Optionशायद इस मामले को सबसे अच्छा भरता है अगर आपका स्ट्रिंग गैर-अशक्त था। हालाँकि, आप शायद nullवैसे भी एक स्ट्रिंग मान के लिए उपयोगकर्ता इनपुट की जाँच करने जा रहे हैं , इसलिए मैं शायद पूछताछ की पहली पंक्ति में वापस आ जाऊँगा: मैं कितने प्रकार के मूल्यों का प्रतिनिधित्व करना चाहता / करती हूँ।
3. क्या nullमेरी प्रोग्रामिंग भाषा में प्रोग्रामर की त्रुटि का संकेत है? दुर्भाग्य से, nullअक्सर कुछ भाषाओं में अनइंस्टाल्यूटेड (या गैर-स्पष्ट रूप से प्रारंभिक) संकेत या संदर्भ के लिए डिफ़ॉल्ट मान होता है। क्या nullडिफ़ॉल्ट मान के रूप में एक मूल्य स्वीकार्य है? क्या यह डिफ़ॉल्ट मान के रूप में सुरक्षित है ? कभी-कभी nullडीललॉक्ड मूल्यों का संकेत होता है। क्या मुझे अपने इंटरफ़ेस के उपभोक्ताओं को इन संभावित मेमोरी मैनेजमेंट या उनके प्रोग्राम में इनिशियलाइज़ेशन समस्याओं के संकेत के साथ प्रदान करना चाहिए? ऐसी समस्याओं का सामना करने में ऐसी कॉल की विफलता मोड क्या है? क्या कॉलर उसी प्रक्रिया या थ्रेड के रूप में मेरा है ताकि ऐसी त्रुटियां मेरे आवेदन के लिए एक उच्च जोखिम हो?

इन सवालों के आपके जवाबों के आधार पर, आप शायद nullअपने इंटरफ़ेस के लिए सही हैं या नहीं , इस पर विचार कर पाएंगे ।

उदाहरण 1

1. आपका एप्लिकेशन सुरक्षा महत्वपूर्ण है
2. आप स्टार्टअप पर कुछ प्रकार के हीप आरंभीकरण का उपयोग कर रहे हैं और nullएक स्ट्रिंग के लिए स्थान आवंटित करने में विफलता पर वापस पारित एक संभावित स्ट्रिंग मान है।
3. ऐसी क्षमता है कि आपका स्ट्रिंग आपके इंटरफेस को हिट करता है

उत्तर: nullशायद उचित नहीं है

तर्क: nullइस मामले में वास्तव में दो अलग-अलग प्रकार के मूल्यों को इंगित करने के लिए उपयोग किया जाता है। पहला एक डिफ़ॉल्ट मान हो सकता है जिसे आपके इंटरफ़ेस का उपयोगकर्ता सेट करना चाहता है। दुर्भाग्य से, दूसरा मान यह दर्शाता है कि आपका सिस्टम ठीक से काम नहीं कर रहा है। ऐसे मामलों में, आप संभवतः जितना संभव हो उतना सुरक्षित रूप से विफल होना चाहते हैं (जो भी आपके सिस्टम के लिए इसका मतलब है)।

उदाहरण 2

1. आप एक सी संरचना का उपयोग कर रहे हैं जिसमें एक char *सदस्य है।
2. आपका सिस्टम हीप आवंटन का उपयोग नहीं करता है और आप MISRA चेकिंग का उपयोग कर रहे हैं।
3. आपका इंटरफ़ेस इस संरचना को एक पॉइंटर के रूप में स्वीकार करता है और यह सुनिश्चित करने के लिए जांचता है कि संरचना इंगित नहीं करती है NULL
4. char *आपके API के लिए सदस्य के डिफ़ॉल्ट और सुरक्षित मान को एकल मान द्वारा इंगित किया जा सकता हैNULL
5. अपने उपयोगकर्ता के आरंभिक प्रारंभ होने पर, आप उपयोगकर्ता को char *सदस्य को प्रारंभिक रूप से स्पष्ट नहीं करने की संभावना प्रदान करना चाहेंगे ।

उत्तर: NULLउपयुक्त हो सकता है

Rationale: इस बात की थोड़ी सी संभावना है कि आपकी संरचना NULLचेक को पास कर दे, लेकिन यह अनैतिक है। हालाँकि, आपका API तब तक इसका हिसाब नहीं दे सकता, जब तक कि आपके पास संरचना के मूल्य के कुछ प्रकार के चेकसम और संरचना के पते की / या रेंज की जाँच न हो। MISRA-C लिंटर्स उनके API के उपयोगकर्ताओं को उनके आरंभ से पहले स्ट्रक्चर्स के उपयोग को चिह्नित करके मदद कर सकते हैं। हालाँकि, char *सदस्य के लिए, यदि सूचक एक आरंभिक संरचना को इंगित करने के लिए है, तो NULLकिसी संरचना आरम्भिक में अनिर्दिष्ट सदस्य का डिफ़ॉल्ट मान है। इसलिए, आपके अनुप्रयोग में संरचना सदस्य के NULLलिए एक सुरक्षित, डिफ़ॉल्ट मान के रूप में काम कर सकता है char *।

यदि यह एक धारावाहिक इंटरफ़ेस पर है, तो मैं खुद से निम्नलिखित प्रश्न पूछूंगा कि क्या किसी स्ट्रिंग पर नल का उपयोग करना है या नहीं।

1. क्या nullसंभावित ग्राहक पक्ष की त्रुटि का संकेत है? जावास्क्रिप्ट में JSON के लिए, यह संभवतः एक nullऐसा नहीं है जो जरूरी नहीं है कि आवंटन विफलता के संकेत के रूप में उपयोग किया जाए। जावास्क्रिप्ट में, इसका उपयोग स्पष्ट रूप से सेट किए जाने वाले संदर्भ से ऑब्जेक्ट अनुपस्थिति के स्पष्ट संकेत के रूप में किया जाता है। हालाँकि, गैर-जावास्क्रिप्ट पार्सर और धारावाहिक हैं, जो कि JSON का नक्शा बनाते हैंnull देशी nullप्रकार के । यदि यह मामला है, तो यह चर्चा करता है कि nullआपकी विशेष भाषा, पार्सर और धारावाहिक संयोजन के लिए देशी उपयोग ठीक है या नहीं ।
2. क्या संपत्ति के मूल्य की स्पष्ट अनुपस्थिति एक एकल संपत्ति मूल्य से अधिक प्रभाव डालती है? कभी-कभी nullवास्तव में यह संकेत मिलता है कि आपके पास एक नया संदेश प्रकार है। यह पूरी तरह से अलग संदेश प्रकार को निर्दिष्ट करने के लिए क्रमांकन प्रारूप के आपके उपभोक्ताओं के लिए क्लीनर हो सकता है। यह सुनिश्चित करता है कि उनके सत्यापन और अनुप्रयोग तर्क में आपके वेब इंटरफ़ेस द्वारा प्रदान किए गए संदेशों के दो भेदों के बीच साफ अलगाव हो सकता है।

सामान्य सलाह

nullएक किनारे या इंटरफ़ेस पर एक मूल्य नहीं हो सकता है जो इसका समर्थन नहीं करता है। यदि आप कुछ ऐसा उपयोग कर रहे हैं जो प्रकृति के गुणों (यानी JSON) के टाइपिंग पर बहुत ढीला है, तो उपभोक्ताओं के किनारे के सॉफ्टवेयर (जैसे JSON स्कीमा ) पर स्कीमा या सत्यापन के कुछ प्रकार को धकेलने का प्रयास करें । यदि यह एक प्रोग्रामिंग भाषा एपीआई है, तो उपयोगकर्ता इनपुट को वैधानिक रूप से सत्यापित करें यदि संभव हो तो (टाइपिंग के माध्यम से) या जितना जोर से रनटाइम में समझदार हो (उर्फ अभ्यास रक्षात्मक प्रोग्रामिंग उपभोक्ता सामना करने वाले इंटरफेस पर )। जैसा कि महत्वपूर्ण है, दस्तावेज़ को किनारे पर परिभाषित करें या इसमें कोई प्रश्न न हो:

• किसी दी गई संपत्ति का मूल्य किस प्रकार का है
• किसी संपत्ति के लिए मूल्य की कौन सी सीमाएँ मान्य हैं।
• कुल प्रकार को कैसे संरचित किया जाना चाहिए। एक समग्र प्रकार में क्या गुण होना चाहिए / मौजूद होना चाहिए?
• यदि यह किसी प्रकार का कंटेनर है, तो कंटेनर कितने आइटमों को रख सकता है या रखना चाहिए, और कंटेनर को किस प्रकार के मान हैं?
• क्या आदेश, यदि कोई हो, तो कंटेनर या समुच्चय प्रकार के गुण या उदाहरण लौटाए गए हैं?
• विशेष मूल्य निर्धारित करने के क्या दुष्प्रभाव हैं और उन मूल्यों को पढ़ने के क्या दुष्प्रभाव हैं?

Answer 4

यहाँ इन सवालों का मेरा व्यक्तिगत विश्लेषण। यह किसी भी पुस्तक, कागज, अध्ययन या जो भी हो, केवल मेरे व्यक्तिगत अनुभव द्वारा समर्थित नहीं है।

के रूप में खाली तार null

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

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

बनाम परिभाषित नहीं है null

यह एक काला या सफेद विषय नहीं है। दोनों दृष्टिकोणों के पक्ष और विपक्ष हैं।

स्पष्ट रूप से परिभाषित nullमूल्यों के पक्ष में , ये नियम हैं:

• संदेश अधिक स्व-वर्णनात्मक होते हैं, जिसमें आपको किसी भी संदेश को देखकर सभी कुंजियों का पता चल जाता है
• पिछले बिंदु से संबंधित, डेटा के उपभोक्ता में त्रुटियों को कोड करना और पता लगाना आसान है: यदि आप गलत कुंजी (शायद गलत तरीके से, एपीआई बदल गया है, आदि) लाने पर त्रुटियों का पता लगाना आसान है।

गैर मौजूदा कुंजी को संभालने के पक्ष में null:

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

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

उस सभी ने कहा, सबसे महत्वपूर्ण बात: अपने इरादे स्पष्ट रूप से और सुसंगत होना। एक काम यहाँ मत करो और दूसरा वहाँ। प्रिडिक्टेबल सॉफ्टवेयर बेहतर सॉफ्टवेयर है।

Comments

रिक्त स्ट्रिंग्स का उपयोग करने के लिए उदाहरण मुझे कार्यान्वयन विस्तार से मतलब है, अर्थात डेटाबेस पंक्तियों को उजागर करने के लिए एपीआई का उपयोग किया जाता है। यदि कोई डेटाबेस शामिल नहीं है और विशुद्ध रूप से ऑब्जेक्ट प्रतिनिधित्व को स्थानांतरित करने के लिए कोई फर्क पड़ेगा?

— imel96

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

— bgusach

मैं अशक्त साथी संदर्भ के साथ ठीक हूं, इसका मतलब है कि कोई साथी नहीं है और संदर्भ भी स्ट्रिंग नहीं है। लेकिन पार्टनर का नाम एक स्ट्रिंग है, भले ही आप अशक्त को पार्टनर के नाम के रूप में अनुमति देते हैं, क्या आप उस नल को नहीं पकड़ेंगे और इसे किसी बिंदु पर खाली स्ट्रिंग के साथ बदल देंगे?

— imel96

अगर कोई साथी नहीं है, तो मैं nullएक खाली स्ट्रिंग के लिए नहीं बदलूंगा। शायद इसे एक रूप में प्रस्तुत करना, लेकिन डेटा मॉडल में कभी नहीं।

— बेगूसच

मेरा मतलब कोई साथी नहीं था, साथी एक वस्तु होगा। यह वह साथी nameहै जिसके बारे में मैं बात कर रहा था, क्या आप भागीदार के नाम को शून्य होने देंगे?

— imel96

Answer 5

मैं एक ऐसी स्थिति में एक खाली स्ट्रिंग की आपूर्ति करूंगा जहां एक स्ट्रिंग मौजूद है, और यह एक खाली स्ट्रिंग होने के लिए होता है। मैं ऐसी स्थिति में नल की आपूर्ति करूंगा जहां मैं स्पष्ट रूप से कहना चाहता हूं "नहीं, यह डेटा नहीं है"। और "कोई डेटा नहीं है, परेशान मत करो" कहने के लिए कुंजी को छोड़ दें।

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

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

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

Comments

मुझे आपकी बात पसंद है "यदि ग्राहक द्वारा प्रतिष्ठित होने की आवश्यकता है"।

— imel96

Answer 6

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

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

यदि आप हमेशा स्ट्रिंग के साथ उसी तरह से बातचीत करते हैं तो यह संभवत: आपके सिर में रहने के लिए कार्यक्षमता के लिए आसान होगा ।

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

यह देखते हुए कि आप एक एपीआई बना रहे हैं, मैं खाली स्ट्रिंग से चिपके रहने की सलाह दूंगा क्योंकि उपयोगकर्ता के लिए क्षतिपूर्ति करना कम है, क्योंकि एक एपीआई के उपयोगकर्ता के रूप में मुझे हर कारण नहीं पता होगा कि आपका एपीआई मुझे एक शून्य मान दे सकता है जब तक कि आप ' बहुत अच्छी तरह से प्रलेखित, जो कुछ उपयोगकर्ता वैसे भी नहीं पढ़ेंगे।

Comments

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

— imel96

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

— एडरिक आयरनॉर्स

Answer 7

दस्तावेज़!

टी एल; डॉ>

जैसा कि आप फिट दिखते हैं - कभी-कभी वह संदर्भ जिसमें इसका इस्तेमाल किया जाता है। उदाहरण के लिए, ओरेकल एसक्यूएल को बाइंड वेरिएबल्स: खाली स्ट्रिंग की व्याख्या एक नल के रूप में की जाती है।

बस मैं कहूंगा - सुनिश्चित करें कि आपने प्रत्येक परिदृश्य का उल्लेख किया है

• शून्य
• खाली (खाली)
• गुम (हटाए गए)

आपका कोड इसके लिए अलग-अलग तरीकों से कार्य कर सकता है - दस्तावेज़ यह बताता है कि आपका कोड इस पर कैसे प्रतिक्रिया देता है:

• विफल (अपवाद आदि), शायद सत्यापन भी विफल हो जाता है (संभवतः एक अपवाद अपवाद) बनाम स्थिति को सही ढंग से नहीं संभाल सकता है (NullPointerException)।
• उचित चूक प्रदान करें
• कोड अलग व्यवहार करता है

फिर इसके अलावा - यह लगातार व्यवहार करने के लिए आप पर निर्भर है, और संभवतः अपनी खुद की कुछ सर्वोत्तम प्रथाओं को अपनाएं। दस्तावेज़ जो लगातार व्यवहार करता है। उदाहरण:

• नल और मिसिंग को समान मानें
• एक खाली स्ट्रिंग का इलाज बिल्कुल वैसा ही करें। केवल SQL बाइंड के मामले में, इसे एक रिक्त माना जा सकता है। सुनिश्चित करें कि आपका SQL लगातार और अपेक्षित तरीके से व्यवहार करता है।

Comments

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

— imel96

Answer 8

tl; dr - यदि आप इसका उपयोग करते हैं: इसका मतलब क्या है में सुसंगत रहें।

यदि आप शामिल करते हैं null, तो इसका क्या अर्थ होगा? चीजों का एक ब्रह्मांड है इसका क्या मतलब हो सकता है। एक मान बस एक लापता या अज्ञात मूल्य का प्रतिनिधित्व करने के लिए पर्याप्त नहीं है (और ये केवल संभावनाओं के असंख्य में से दो हैं: जैसे कि गुम - यह मापा गया था, लेकिन हम अभी तक इसे नहीं जानते हैं। अज्ञात - हमने मापने की कोशिश नहीं की। यह।)

एक उदाहरण में मैं हाल ही में आया था, एक क्षेत्र खाली हो सकता है क्योंकि यह किसी की गोपनीयता की रक्षा करने के लिए रिपोर्ट नहीं किया गया था, लेकिन यह प्रेषक के पक्ष में जाना जाता था, प्रेषक के पक्ष में नहीं जाना जाता था, लेकिन मूल रिपोर्टर या अज्ञात दोनों को जानते हैं। और ये सभी रिसीवर के लिए मायने रखते हैं। इसलिए आमतौर पर एक मूल्य पर्याप्त नहीं है।

एक खुली दुनिया की धारणा के साथ (आप बस नहीं बताई गई चीजों के बारे में नहीं जानते हैं), आप बस इसे छोड़ देंगे और यह कुछ भी हो सकता है। बंद दुनिया धारणा (बताई गई बातें झूठी हैं, उदाहरण के लिए SQL में) आप बेहतर तरीके से स्पष्ट कर सकते हैं कि nullइसका क्या अर्थ है और उस परिभाषा के अनुरूप होना चाहिए जो आप कर सकते हैं ...