आपका प्रश्न।
लेकिन, लेकिन - मेरे भोलेपन से, मुझे चीखने दो - कभी-कभी एक मूल्य सार्थक रूप से अनुपस्थित हो सकता है!
पूरी तरह से आपके साथ वहाँ पर। हालाँकि, कुछ कैविएट हैं जिन्हें मैं एक सेकंड में प्राप्त करूँगा। लेकिन पहले:
नल बुराई हैं और जब भी संभव हो बचना चाहिए।
मुझे लगता है कि यह एक सुविचारित लेकिन अतिरंजित बयान है।
नल दुष्ट नहीं हैं। वे एक एंटीपैटर्न नहीं हैं। वे ऐसी कोई चीज नहीं हैं, जिसे हर कीमत पर टाला जाए। हालांकि, नल त्रुटि के लिए प्रवृत्त हैं (अशक्त से जाँच करने में विफल)।
लेकिन मुझे समझ नहीं आ रहा है कि अशक्त के लिए जांच करना कितना असफल है, यह किसी तरह का सबूत है कि अशक्त स्वाभाविक रूप से उपयोग करने के लिए गलत है।
यदि अशक्त बुराई है, तो फिर सरणी इंडेक्स और सी ++ पॉइंटर्स हैं। वे नहीं हैं। वे अपने आप को पैर में मारना आसान समझते हैं, लेकिन उन्हें हर कीमत पर टाला नहीं जाता है।
इस उत्तर के बाकी हिस्सों के लिए, मैं "अशक्त बुराई है" के इरादे को अनुकूलित करने जा रहा हूं एक अधिक बारीक " नल को जिम्मेदारी से संभाला जाना चाहिए "।
आपका समाधान
जबकि मैं एक वैश्विक नियम के रूप में अशक्त के उपयोग पर आपकी राय से सहमत हूं; मैं इस विशेष मामले में अशक्त के आपके उपयोग से सहमत नहीं हूं।
नीचे दी गई प्रतिक्रिया को संक्षेप में प्रस्तुत करने के लिए: आप विरासत और बहुरूपता के उद्देश्य को गलत समझ रहे हैं। जबकि अशक्त का उपयोग करने के आपके तर्क में वैधता है, आपके आगे के "प्रमाण" कि क्यों दूसरा रास्ता खराब है विरासत के दुरुपयोग पर बनाया गया है, आपके बिंदुओं को कुछ हद तक अप्रासंगिक रूप से प्रदान करता है।
अधिकांश अपडेट्स में स्वाभाविक रूप से एक प्लेयर जुड़ा होता है - आखिरकार, यह जानना आवश्यक है कि किस खिलाड़ी ने इस मोड़ को आगे बढ़ाया। हालाँकि, कुछ अपडेट में प्लेयर को सार्थक रूप से उनके साथ जोड़ा नहीं जा सकता है।
यदि ये अपडेट सार्थक रूप से भिन्न हैं (जो वे हैं), तो आपको दो अलग-अलग अपडेट प्रकारों की आवश्यकता है।
उदाहरण के लिए, संदेशों पर विचार करें। आपके पास त्रुटि संदेश और IM चैट संदेश हैं। लेकिन जब वे बहुत समान डेटा (एक स्ट्रिंग संदेश और एक प्रेषक) हो सकते हैं, तो वे उसी तरह व्यवहार नहीं करते हैं। उन्हें अलग-अलग वर्गों के रूप में, अलग-अलग उपयोग किया जाना चाहिए।
अब आप जो कुछ भी कर रहे हैं, वह प्लेयर प्रॉपर्टी की अशक्तता के आधार पर दो प्रकार के अपडेट के बीच प्रभावी रूप से अंतर कर रहा है। यह IM संदेश और त्रुटि कोड के अस्तित्व के आधार पर एक त्रुटि संदेश के बीच निर्णय लेने के बराबर है। यह काम करता है, लेकिन यह सबसे अच्छा तरीका नहीं है।
- जेएस कोड अब केवल एक परिभाषित संपत्ति के रूप में प्लेयर के बिना एक ऑब्जेक्ट प्राप्त करेगा, जो वैसा ही है जैसे कि यह शून्य था क्योंकि दोनों मामलों में चेक की आवश्यकता होती है यदि मूल्य मौजूद है या अनुपस्थित है;
आपका तर्क बहुरूपता के दुखों पर निर्भर करता है। यदि आपके पास कोई ऐसा तरीका है जो किसी GameUpdateवस्तु को लौटाता है , तो इसे आम तौर पर कभी भी अंतर करने की परवाह नहीं करनी चाहिए GameUpdate, PlayerGameUpdateया NewlyDevelopedGameUpdate।
एक बेस क्लास के लिए एक पूरी तरह से काम करने का अनुबंध होना चाहिए, अर्थात इसके गुणों को बेस क्लास पर परिभाषित किया गया है न कि व्युत्पन्न वर्ग पर (जो कहा जा रहा है, इन बेस प्रॉपर्टीज का मूल्य निश्चित रूप से व्युत्पन्न वर्गों में ओवरराइड किया जा सकता है)।
यह आपके तर्क को प्रस्तुत करता है। अच्छे व्यवहार में, आपको कभी भी ध्यान नहीं देना चाहिए कि आपकी GameUpdateवस्तु में खिलाड़ी है या नहीं। यदि आप Playerएक की संपत्ति तक पहुँचने की कोशिश कर रहे हैं GameUpdate, तो आप कुछ अतार्किक काम कर रहे हैं।
टाइप की गई भाषाएं जैसे C # भी आपको प्रयास करने की अनुमति नहीं देगा क्योंकि Playerसंपत्ति का उपयोग करने के लिए बस संपत्ति नहीं है। जावास्क्रिप्ट अपने दृष्टिकोण में बहुत अधिक ढीला है (और इसे पूर्वसंचालन की आवश्यकता नहीं है) इसलिए यह आपको सही करने के लिए परेशान नहीं करता है और इसके बजाय रनटाइम पर उड़ा है।GameUpdateGameUpdate
- GameUpdate वर्ग में एक और अशक्त क्षेत्र को जोड़ा जाना चाहिए, मुझे इस desing के साथ जारी रखने के लिए कई विरासत का उपयोग करने में सक्षम होना होगा - लेकिन एमआई अपने आप में बुराई है (अधिक अनुभवी प्रोग्रामर के अनुसार) और इससे भी महत्वपूर्ण बात, सी # नहीं है ऐसा है तो मैं इसका इस्तेमाल नहीं कर सकता।
आपको अशक्त गुणों के आधार पर कक्षाएं नहीं बनानी चाहिए। आपको कार्यात्मक रूप से अनूठे प्रकार के गेम अपडेट के आधार पर कक्षाएं बनानी चाहिए ।
सामान्य रूप से अशक्त मुद्दों से कैसे बचें?
मुझे लगता है कि यह इस बात पर विस्तृत है कि आप किसी मूल्य के अभाव को कैसे सार्थक रूप से व्यक्त कर सकते हैं। यह बिना किसी विशेष क्रम में समाधान (या खराब दृष्टिकोण) का एक संग्रह है।
1. वैसे भी अशक्त उपयोग करें।
यह सबसे आसान तरीका है। हालाँकि, आप अपने आप को एक टन के नल चेक के लिए साइन अप कर रहे हैं और (जब ऐसा करने में विफल रहे) अशक्त संदर्भ अपवादों का निवारण करें।
2. एक गैर-शून्य अर्थहीन मूल्य का उपयोग करें
यहाँ एक सरल उदाहरण है indexOf():
"abcde".indexOf("b"); // 1
"abcde".indexOf("f"); // -1
इसके बदले nullआपको मिलता है -1। तकनीकी स्तर पर, यह एक मान्य पूर्णांक मान है। हालांकि, एक नकारात्मक मूल्य एक निरर्थक उत्तर है क्योंकि अनुक्रमित सकारात्मक पूर्णांक होने की उम्मीद है।
तार्किक रूप से, इसका उपयोग केवल उन मामलों के लिए किया जा सकता है जहां रिटर्न प्रकार अधिक संभव मानों की अनुमति देता है, सार्थक रूप से लौटाए जा सकते हैं (indexOf = सकारात्मक पूर्णांक; int = नकारात्मक और सकारात्मक पूर्णांक)
संदर्भ प्रकारों के लिए, आप अभी भी इस सिद्धांत को लागू कर सकते हैं। उदाहरण के लिए, यदि आपके पास पूर्णांक आईडी के साथ एक इकाई है, तो आप शून्य के विपरीत, इसके आईडी सेट -1 के साथ एक डमी वस्तु वापस कर सकते हैं।
आपको बस एक "डमी राज्य" को परिभाषित करना होगा जिसके द्वारा आप माप सकते हैं कि कोई वस्तु वास्तव में उपयोग करने योग्य है या नहीं।
ध्यान दें कि यदि आप स्ट्रिंग मान को नियंत्रित नहीं करते हैं तो आपको पूर्वनिर्धारित स्ट्रिंग मानों पर भरोसा नहीं करना चाहिए। जब आप किसी खाली वस्तु को वापस करना चाहते हैं, तो आप उपयोगकर्ता के नाम को "अशक्त" करने पर विचार कर सकते हैं, लेकिन जब आपकी सेवा के लिए क्रिस्टोफर नल साइन अप करेंगे तो आपको समस्याएँ आएंगी ।
3. इसके बजाय एक अपवाद फेंको।
नहीं, बस नहीं। अपवादों को तार्किक प्रवाह के लिए नियंत्रित नहीं किया जाना चाहिए।
कहा जा रहा है कि, कुछ ऐसे मामले हैं जहाँ आप (अशक्त) अपवाद को छिपाना नहीं चाहते, बल्कि एक उपयुक्त अपवाद दिखाना चाहते हैं। उदाहरण के लिए:
var existingPerson = personRepository.GetById(123);
यह एक PersonNotFoundException(या समान) फेंक सकता है जब आईडी 123 के साथ कोई व्यक्ति नहीं है।
कुछ हद तक स्पष्ट रूप से, यह केवल उन मामलों के लिए स्वीकार्य है, जहां कोई आइटम नहीं ढूंढना किसी भी आगे की प्रक्रिया को करना असंभव बनाता है। यदि कोई आइटम नहीं मिल रहा है और आवेदन जारी रह सकता है, तो आपको एक अपवाद फेंकना चाहिए । मैं इस पर अधिक जोर नहीं दे सकता हूं।