जो आप स्वीकार करते हैं उसमें उदार रहें… या नहीं?

Question

[अस्वीकरण: यह प्रश्न व्यक्तिपरक है, लेकिन मैं तथ्यों और / या प्रतिसाद द्वारा समर्थित उत्तर प्राप्त करना पसंद करूंगा]

मुझे लगता है कि हर कोई रोबस्टनेस सिद्धांत के बारे में जानता है , आमतौर पर डाक कानून द्वारा अभिव्यक्त किया गया है:

जो आप भेजते हैं उसमें रूढ़िवादी रहें; आप जो स्वीकार करते हैं, उसमें उदारता बरतें।

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

मैं हालांकि नोटिस करता हूं कि वहां टीसीपी प्रोटोकॉल का आरएफसी "साइलेंट फेल्योर" स्वीकार करता है जब तक कि अन्यथा निर्दिष्ट न हो ... जो कि कम से कम कहने के लिए एक दिलचस्प व्यवहार है।

सॉफ़्टवेयर ट्रेड भर में इस सिद्धांत के अनुप्रयोग के अन्य उदाहरण हैं जो नियमित रूप से पॉप अप करते हैं क्योंकि उनके सिर के ऊपर से, काटे गए डेवेलपर्स हैं:

• जावास्क्रिप्ट अर्ध-बृहदान्त्र सम्मिलन
• सी (चुप) बिलियन रूपांतरण (जो खराब नहीं होगा अगर इसे छोटा नहीं किया जाता ...)

और "स्मार्ट" व्यवहार को लागू करने में मदद करने के लिए उपकरण हैं:

• नाम का मेल ध्वन्यात्मक एल्गोरिदम ( डबल मेटाफोन )
• स्ट्रिंग दूरी एल्गोरिदम ( लेवेंसहाइट दूरी )

हालाँकि मुझे लगता है कि यह दृष्टिकोण, जबकि यह गैर-तकनीकी उपयोगकर्ताओं के साथ काम करते समय या त्रुटि सुधार की प्रक्रिया में उपयोगकर्ताओं की मदद करने में मददगार हो सकता है, पुस्तकालय / कक्षाओं के इंटरफेस के डिजाइन पर लागू होने पर कुछ कमियां हैं:

• यह कुछ हद तक व्यक्तिपरक है कि क्या एल्गोरिथ्म "सही" अनुमान लगाता है, और इस प्रकार यह सिद्धांत के सिद्धांत के खिलाफ जा सकता है
• यह कार्यान्वयन को और अधिक कठिन बना देता है, इस प्रकार बग्स ( YAGNI का उल्लंघन ) शुरू करने की अधिक संभावना है ?
• यह व्यवहार को बदलने के लिए अतिसंवेदनशील बनाता है, क्योंकि "अनुमान" दिनचर्या का कोई भी संशोधन पुराने कार्यक्रमों को तोड़ सकता है, लगभग शुरू होने वाली संभावनाओं को छोड़कर ...!

और यही मुझे निम्नलिखित प्रश्न की ओर ले गया:

जब एक इंटरफ़ेस (पुस्तकालय, कक्षा, संदेश) डिजाइन करते हैं, तो क्या आप मजबूती के सिद्धांत की ओर झुकते हैं या नहीं?

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

Comments

मुझे आश्चर्य है कि HTML और सामान्य डेटा में क्या अंतर है? मजबूती का सिद्धांत संचार के बारे में है। एक लिखता है - एक पढ़ता है। क्यों नेटवर्क संचार दृश्य या एपीआई से अलग है? मेरे पास एक एपीआई उदाहरण है जहां हम जो स्वीकार करते हैं उस पर उदार होने का सिद्धांत प्रोग्रामर हैं जो उपयोगकर्ताओं के जीवन को सरल बनाता है, कोड आकार को कम करता है और इसलिए, प्रदर्शन में सुधार करता है + बग को समाप्त करता है। देखो stackoverflow.com/questions/18576849

— वैल

@ वाल: वास्तव में, आपका उदाहरण मेल नहीं खाता। "आप जो स्वीकार करते हैं उसमें उदार होना" केवल आधार / व्युत्पन्न का मामला नहीं है, यह उससे परे है और थोड़ा गलत इनपुट भी स्वीकार (और व्याख्या) कर रहा है।

— मथिउ एम।

किसी मामले को दिखाने से उस मामले को कैसे नहीं दिखाया जाता है?

— वैल

Answer 1

जब यह अस्पष्टता का परिचय नहीं देगा तो मैं इसे मजबूती कहूंगा ।

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

एक स्ट्रिंग गाइड को पार्स करते समय इसे किसी भी सामान्य प्रारूप के साथ या आसपास के घुंघराले ब्रेसिज़ के साथ या बिना किसी भी सामान्य प्रारूप को स्वीकार करना चाहिए।

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

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

Comments

मैं सहमत हूँ, मजबूती जब यह लागत नहीं है तो यह बहुत उपयोगी है।

— मैथ्यू एम।

यहां तक ​​कि अल्पविराम से अलग की गई सूची समस्याओं का कारण बनती है, जैसे: क्रोम और फ़ायरफ़ॉक्स का जावास्क्रिप्ट इंजन {"key": "value",}वैध के रूप में स्वीकार करने लगता है, IE नहीं। जब तक मैं JSlint के साथ अपनी निर्माण प्रक्रिया में सुधार नहीं करता, तब तक मैं अक्सर इस विशेष समस्या पर लड़खड़ाया।

— कीपला

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

— दावी 8

@ Davy8: ट्रेलिंग कॉमा अवैध लगती है ( stackoverflow.com/questions/5139205/… )। मैं इस पर भरोसा नहीं करना चाहता, मेरी बात यह है कि जब पर्याप्त लोग इनपुट स्वीकार करते हैं, तो यह वास्तविक रूप से मानक हो जाता है (क्योंकि किसी का ध्यान नहीं जाता है कि यह एक त्रुटि है), जो हमें HTML में सामने आई किसी चीज़ की ओर ले जाता है: कि त्रुटियाँ इतने सामान्य हो जाते हैं कि आप उन्हें अब बुरे इनपुट के रूप में अनदेखा नहीं कर सकते।

— कीपला

@keppla, जिसे moz और Chrome में विफल होना चाहिए। मुख्य रूप से JS देव के रूप में, यह मुझे नाराज कर देता है कि यह नहीं करता है (यह कम से कम मोज़े में इस्तेमाल होता है)। यह डिबग को कठिन बनाता है, आसान नहीं। IE वह कर रहा है जो वह करने वाला है। विफल @ खराब कोड। HTML एक चीज है। हमें स्क्रिप्टिंग भाषा में इस बकवास की आवश्यकता नहीं है। यह रोबस्ट सिद्धांत के भयानक अनुप्रयोग का एक उदाहरण है, जो कुछ ब्राउज़र विक्रेताओं पर उत्कृष्ट है।

— एरिक रेपेन

Answer 2

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

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

Answer 3

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

सुधार की अधिकता से आप अपने ग्राहकों को छोटी-मोटी त्रुटियां करने के अधिकार से वंचित कर देते हैं, जो तब तक ठीक है जब तक वे शिकायत करते हैं कि उनका सामान आपके प्रतियोगी उत्पाद पर ठीक काम करता है, और आपको बताता है कि आप अपने 5,000 पृष्ठ मानक के साथ क्या कर सकते हैं "DRAFT" अभी भी क्रेयॉन में कवर पर बिखरा हुआ है, और कम से कम 3 विशेषज्ञों का दावा मौलिक रूप से त्रुटिपूर्ण है, और 200 अधिक ईमानदार विशेषज्ञों का कहना है कि वे पूरी तरह से नहीं समझते हैं।

मेरा व्यक्तिगत समाधान हमेशा पदावनति रहा है। आप उनका समर्थन करते हैं, लेकिन उन्हें बताएं कि वे गलत कर रहे हैं, और (यदि संभव हो तो) शुद्धता का सबसे आसान रास्ता है। इस तरह, जब आप बग-फ़ीचर को 10 साल की लाइन से नीचे कर देते हैं, तो आपको कम से कम यह बताने के लिए कागज़ का निशान होता है कि "हमने आपको चेतावनी दी थी कि ऐसा हो सकता है।"

Comments

के लिए +1 निंदा , यह वास्तव में एक महत्वपूर्ण अवधारणा है और मैं हैरान हूँ कि यह अब तक अनदेखा किया गया।

— मैथ्यू एम।

Answer 4

दुर्भाग्य से तथाकथित "मजबूती सिद्धांत" मजबूती के लिए नेतृत्व नहीं करता है। उदाहरण के तौर पर HTML को लें। यदि ब्राउज़र ने विकृत सामग्री के अर्थ का अनुमान लगाने की कोशिश करने के बजाय शुरुआत से ही HTML को सख्ती से पार्स कर दिया होता तो बहुत परेशानी, आँसू, समय और ऊर्जा की बर्बादी से बचा जा सकता था।

ब्राउज़र को कवर के नीचे इसे ठीक करने के बजाय बस एक त्रुटि संदेश प्रदर्शित करना चाहिए था। इसने सभी बंगलों को अपनी गंदगी ठीक करने के लिए मजबूर किया होगा।

Comments

अपने आप को उद्धृत करते हुए (पुराना हो रहा होगा): "हालाँकि मैंने हमेशा सोचा है कि HTML / CSS के लिए इसका अनुप्रयोग कुल विफलता थी"

— Matthieu M.

सच है, लेकिन बहुत ही दोष सहिष्णुता ने भी वेब को इतना लोकप्रिय बनाने में मदद की।

— 16

ब्राउज़र विक्रेता उस एक पर विफल रहे। Doctypes के साथ हमारे पास इस संबंध में अपनी पसंद बनाने की क्षमता थी, लेकिन उस दिन के अंत में सब कुछ बहुत हद तक उसी तरह का व्यवहार करने लगा जब तक कि आपके पास कोई भी सिद्धांत घोषित नहीं हुआ। अब उन्हें लगता है कि विफलता से निपटने के तरीके के बारे में पालन करने के लिए सटीक नियमों का एक हाइपर-कॉम्प्लेक्स सेट है? मुझे लगता है कि वे समस्या की पहचान करने में विफल हो रहे हैं।

— एरिक रेपेन

आप कह रहे हैं कि असफल-तेज, जो "मजबूत" के विपरीत है, अधिक कुशल है।

— वैल

@MaR: क्या ऐसा है? बहुत ही विवादित, बहुत अधिक संभावनाएं महत्वपूर्ण थीं।

— Deduplicator

Answer 5

मैं इंटरफेस को कई समूहों में विभाजित करता हूं (यदि आपको पसंद है तो अधिक जोड़ें):

1. जो आपके नियंत्रण में हैं वे सख्त होने चाहिए (आमतौर पर कक्षाएं)
2. लाइब्रेरी एपीआई, जो सख्त पक्ष में भी होना चाहिए, लेकिन अतिरिक्त सत्यापन की सलाह दी जाती है
3. सार्वजनिक इंटरफेस जो कि आने वाले हर प्रकार के दुरुपयोग को संभालना चाहिए (आमतौर पर प्रोटोकॉल, उपयोगकर्ता इनपुट आदि)। यहाँ इनपुट पर मजबूती वास्तव में भुगतान करती है, आप उम्मीद नहीं कर सकते कि हर कोई अपना सामान ठीक करने जा रहा है। और उपयोगकर्ता के लिए याद रखें कि यदि एप्लिकेशन काम नहीं करता है तो यह आपकी गलती होगी, न कि उस पार्टी ने जिसने कुछ बीमार प्रारूप भेजा है।

आउटपुट हमेशा सख्त होना चाहिए।

Answer 6

मुझे लगता है कि HTML और वर्ल्ड वाइड वेब ने रोबस्टनेस सिद्धांत की एक व्यापक पैमाने पर वास्तविक दुनिया परीक्षण प्रदान किया है और इसे बड़े पैमाने पर विफलता दिखाया है। यह प्रतिस्पर्धी HTML के लगभग गड़बड़ मानकों के लिए सीधे जिम्मेदार है जो वेब डेवलपर्स (और उनके उपयोगकर्ताओं) के लिए जीवन दुखी बनाता है और हर नए इंटरनेट एक्सप्लोरर रिलीज के साथ खराब हो जाता है।

हम 1950 के दशक से जानते हैं कि कोड को ठीक से कैसे मान्य किया जाए। एक सख्त पार्सर के माध्यम से इसे चलाएं और अगर कुछ वाक्य रचना में सही नहीं है, तो एक त्रुटि और गर्भपात करें। पास मत जाओ, $ 200 इकट्ठा मत करो, और सभी के प्यार के लिए जो कि द्विआधारी है कुछ कंप्यूटर प्रोग्राम को कोडर के दिमाग को पढ़ने का प्रयास नहीं करने देता है अगर उसने कोई गलती की है!

HTML और जावास्क्रिप्ट ने हमें वही दिखाया है जब उन सिद्धांतों को अनदेखा किया जाता है। कार्रवाई का सबसे अच्छा तरीका उनकी गलतियों से सीखना है और उन्हें दोहराना नहीं है।

Comments

@ChaosPandion: समस्या केवल इंटरनेट एक्सप्लोरर के साथ नहीं है, जो मुझे लगता है, लेकिन उन सभी गैर-मानक वेब पृष्ठों के साथ जिन्हें पिछले संस्करणों द्वारा स्वीकार किया गया था और सभी को अब साथ रहना होगा ... और कम या ज्यादा सफलतापूर्वक साथ रहने का प्रयास करें।

— मैथ्यू एम।

मुझे वास्तव में लगता है कि IE टीम सभी ब्राउज़र डेवलपर्स की सबसे खराब स्थिति में है। जोएल ने मेरे विचारों को बहुत अच्छी तरह से गाया ।

— डीन हार्डिंग

यह डेवलपर्स और डिजाइनरों के लिए जीवन दयनीय बना सकता है, लेकिन तब हम बहुत धीरे-धीरे विकसित होने और स्थिर मानक के साथ फंस गए होंगे - मुझे संदेह है कि वेब ऐसा होगा जैसा अब दिया गया है। असली विजेता वेब ब्राउज़ करने वाले लोग हैं और दिन के अंत में वे लोग हैं जो गिनती करते हैं।

— फिनकेक

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

— डेवॉर्ड

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

— डेवॉर्ड

Answer 7

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

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

जारगॉन फ़ाइल में एक उपयोगकर्ता की मंशा "अनुमान लगाने" पर एक डरावनी कहानी भी है ।

Comments

बहुत मनोरंजक कहानी :) मुझे एहसास है कि जब आप मौजूदा सिस्टम के साथ बातचीत करने की कोशिश करते हैं, तो आपको अधिक लेवे की आवश्यकता हो सकती है, क्योंकि अगर यह आपके काम नहीं करता है तो आपको दोषी ठहराया जाएगा।

— मैथ्यू एम।

वास्तव में, यदि आपका फोन अधिकांश अन्य फोन के साथ काम नहीं करता है, तो आपका फोन खराब है ।

— सामब

@SBB: खराब को टूटे हुए से बदलें ।

— डेवॉर्ड

Answer 8

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

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

एक तरफ के रूप में, मुझे लगता है कि टीसीपी प्रोटोकॉल में "मूक विफलता" की अनुमति है क्योंकि अन्यथा, यदि लोग आप पर विकृत पैकेट फेंक रहे थे, तो आपको त्रुटि संदेशों के साथ बमबारी की जाएगी। यह वहीं साधारण DoS सुरक्षा है।

Comments

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

— डेवॉर्ड

Answer 9

IMO, मजबूती एक डिज़ाइन ट्रेड-ऑफ़ का एक पक्ष है जो "पसंद" सिद्धांत नहीं है। जैसा कि कई ने बताया है, चार घंटे उड़ाने जैसी कोई चीज नहीं है, जिसमें यह पता लगाने की कोशिश की जा रही है कि आपका जेएस केवल वास्तविक समस्या का पता लगाने के लिए गलत हो गया था, केवल एक ब्राउज़र ने एक्सएचटीएमएल स्ट्रिक्ट के साथ उचित काम किया था। यह पृष्ठ को टुकड़ों में जाने देता है जब सेवा किए गए एचटीएमएल का कुछ हिस्सा पूर्ण आपदा था।

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

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

बुद्धिमान और इंटरफ़ेस-संगत तरीके से ओवरलोडिंग args चीजों के बारे में मजबूत होने का एक स्मार्ट तरीका है। तो एक ऐसी प्रणाली में अतिरेक पकाना है जहां यह माना जाता है कि पैकेट वितरण नियमित रूप से एक व्यापक रूप से जटिल नेटवर्क में वितरित करने में विफल रहेगा और प्रौद्योगिकी के एक उभरते हुए क्षेत्र में हर किसी के पास संचरण के लिए संभावित साधनों की एक विस्तृत विविधता के साथ चलेगा।

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

1999 के ब्राउज़र पर 2010 की कार्यक्षमता प्रदान करने का प्रयास जब आप केवल एक कम तकनीकी पृष्ठ वितरित कर सकते हैं, तो यह एक मूर्खतापूर्ण डिज़ाइन ट्रेडऑफ़ का एक और उदाहरण है। मैंने उड़ाए गए अवसरों और पैसे को देखा है, जो बग-राइडेड वर्कअराउंड पर बिताए डेवलपर समय पर बर्बाद हो गए हैं, उदाहरण के लिए एक तत्व के ऊपर गोल-गोल कोनों को पाने के लिए! @ $ $ ग्रेडिएंट बैकग्राउंड उदाहरण के लिए, मुझे पूरी तरह से उड़ा दिया है। और किस लिए? उच्च तकनीक वाले ब्राउज़रों को वितरित करने के लिए जो उच्च अंत ब्राउज़रों पर आपकी पसंद को सीमित करते हुए सिद्ध टेक्नोफोब के लिए खराब प्रदर्शन करते हैं।

इसके लिए सही विकल्प होने के लिए, एक मजबूत तरीके से इनपुट को संभालने का विकल्प हमेशा शॉर्ट और लॉन्ग टर्म आईएमओ में समस्या के दोनों तरफ जीवन को आसान बनाना चाहिए।

Comments

"एक विधि के लिए जो 20 तर्क लेती है"> आगे देखने की आवश्यकता नहीं है, 5/6 के बाद विधि गलत है । हालांकि उत्तर के लिए धन्यवाद :)

— Matthieu M.

Answer 10

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

इसके अलावा, जैसा कि पहले ही बताया गया है, यह इस बात पर निर्भर करता है कि उपयोगकर्ता वास्तव में क्या अनुमान लगाता है, यह वास्तव में कितना कठिन है। यदि यह बहुत आसान है, तो आपके पास दो मामले हैं:

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

किसी भी मामले में यह 100% स्पष्ट और नियतात्मक नहीं है, कि एक इनपुट को दूसरे में परिवर्तित किया जाना चाहिए, आपको पहले से उल्लेख किए गए कारणों के लिए रूपांतरण नहीं करना चाहिए (रिफैक्टरिंग पर संगतता को तोड़ना, कम से कम उपयोगकर्ताओं को चकित करना)।

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

मैं आपको सलाह दूंगा कि आप मेरे इस सवाल को एक ऐसे ही मामले में पढ़ें ।