"एक फ़ंक्शन के लिए तर्कों की आदर्श संख्या शून्य है" स्पष्ट गलत है। तर्कों की आदर्श संख्या आपके फ़ंक्शन को साइड-इफ़ेक्ट फ्री बनाने के लिए आवश्यक संख्या है। इससे कम और आप अनावश्यक रूप से अपने कार्यों को अशुद्ध होने का कारण बनते हैं, जिससे आप सफलता के गर्त से दूर जा सकते हैं और दर्द की गति पर चढ़ सकते हैं। कभी-कभी उनकी सलाह से "अंकल बॉब" हाजिर हो जाता है। कभी-कभी वह शानदार रूप से गलत होता है। उनका शून्य तर्क सलाह उत्तरार्द्ध का एक उदाहरण है
( स्रोत: इस साइट पर एक और सवाल के तहत @ डेविड अरनो द्वारा टिप्पणी )
टिप्पणी ने 133 अपवर्जन की शानदार राशि प्राप्त की है, यही वजह है कि मैं इसकी योग्यता पर कुछ ध्यान देना चाहूंगा।
जहां तक मुझे जानकारी है, प्रोग्रामिंग में दो अलग-अलग तरीके हैं: शुद्ध कार्यात्मक प्रोग्रामिंग (यह टिप्पणी क्या उत्साहजनक है) और बताएं, इस वेबसाइट पर भी समय-समय पर (जो समय-समय पर अनुशंसित नहीं किया जा रहा है) पूछें। AFAIK ये दोनों सिद्धांत मौलिक रूप से असंगत हैं, एक-दूसरे के विरोधी होने के करीब: शुद्ध कार्यात्मक को "केवल रिटर्न मान के रूप में संक्षेपित किया जा सकता है, कोई साइड इफेक्ट नहीं है", जबकि पूछें, संक्षेप में नहीं कहा जा सकता है क्योंकि "कुछ भी वापस न करें," केवल साइड इफेक्ट्स हैं ”। इसके अलावा, मैं हैरान हूँ क्योंकि मैंने सोचा था कि बताओ, मत पूछो कि ओओ प्रतिमान का मूल माना जाता था जबकि शुद्ध कवक को कार्यात्मक प्रतिमान का मूल माना जाता था - अब मुझे OO में अनुशंसित शुद्ध कार्य दिखाई देते हैं!
मुझे लगता है कि डेवलपर्स को इन प्रतिमानों में से किसी एक को चुनना चाहिए और उससे चिपकना चाहिए? वैसे मुझे मानना होगा कि मैं खुद को कभी भी पालन करने के लिए नहीं ला सका। अक्सर यह मेरे लिए एक मूल्य वापस करने के लिए सुविधाजनक लगता है और मैं वास्तव में यह नहीं देख सकता कि मैं केवल साइड इफेक्ट्स के साथ क्या हासिल करना चाहता हूं। अक्सर यह मेरे लिए साइड इफेक्ट्स के लिए सुविधाजनक लगता है और मैं वास्तव में यह नहीं देख सकता कि मैं केवल जो मान लौटाता हूं उसे मैं कैसे हासिल कर सकता हूं। इसके अलावा, अक्सर (मुझे लगता है कि यह भयानक है) मेरे पास ऐसे तरीके हैं जो दोनों करते हैं।
हालांकि, इन 133 अपवोट्स से मैं तर्क दे रहा हूं कि वर्तमान में शुद्ध कार्यात्मक प्रोग्रामिंग "जीत" है क्योंकि यह एक आम सहमति बन जाती है कि यह बताने के लिए बेहतर है, मत पूछो। क्या ये सही है?
इसलिए, इस एंटीपैर्टन-राइडेड गेम के उदाहरण पर मैं बनाने की कोशिश कर रहा हूं : अगर मैं इसे शुद्ध कार्यात्मक प्रतिमान के साथ लाना चाहता था - कैसे ?!
युद्ध की स्थिति होना मुझे उचित लगता है। चूँकि यह एक बारी आधारित खेल है, मैं लड़ाई वाले राज्यों को एक शब्दकोश में रखता हूँ (मल्टीप्लेयर - एक ही समय में कई खिलाड़ियों द्वारा खेली जाने वाली कई लड़ाइयाँ हो सकती हैं)। जब भी कोई खिलाड़ी अपनी बारी करता है, तो मैं युद्ध की स्थिति पर एक उपयुक्त विधि कहता हूं जो (ए) तदनुसार राज्य को संशोधित करता है और (बी) खिलाड़ियों को अपडेट लौटाता है, जो जेएसएन में सिलसिलेवार हो जाते हैं और मूल रूप से सिर्फ उन्हें बताते हैं कि अभी क्या हुआ है मंडल। यह, मुझे लगता है, BOTH सिद्धांतों और एक ही समय में एक प्रमुख उल्लंघन में है।
ठीक है - अगर मैं वास्तव में चाहता था तो मैं इसे संशोधित करने के बजाय एक विधि RETURN को एक युद्ध राज्य बना सकता था। परंतु! क्या मुझे इसके बाद युद्ध की स्थिति में जरूरत की हर चीज को कॉपी करना होगा, ताकि राज्य में इसे संशोधित करने के बजाय पूरी तरह से नया राज्य लौटाया जा सके?
अब शायद अगर चाल एक हमला है तो मैं सिर्फ एक अक्षर एचपी को अपडेट कर सकता हूं? समस्या यह है कि यह सरल नहीं है: खेल के नियम, एक चाल और अक्सर एक खिलाड़ी के एचपी के एक हिस्से को हटाने की तुलना में कई अधिक प्रभाव होंगे। उदाहरण के लिए, यह वर्णों के बीच की दूरी बढ़ा सकता है, विशेष प्रभाव लागू कर सकता है, आदि।
यह मेरे लिए बहुत आसान है कि मैं राज्य को केवल स्थान पर संशोधित करूं और अपडेट लौटाऊं ...
लेकिन एक अनुभवी इंजीनियर इससे कैसे निपटेगा?
