क्या मुझे अपनी लाइब्रेरी का उपयोग करने वाले किसी के लिए पर्यावरण को डिफ़ॉल्ट करना चाहिए?

Question

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

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

मेरा मित्र यह पर्यावरण के लिए डिफ़ॉल्ट और अधिक सुविधाजनक है और यदि उपयोगकर्ता चाहें तो उपयोगकर्ता को ओवरराइड करने दें।

विचार? क्या लोकप्रिय पुस्तकालयों में कोई अच्छा संदर्भ या उदाहरण/पैटर्न हैं जो हमारे तर्कों का समर्थन करते हैं? भी, इस एपीआई डिजाइन बिंदु पर चर्चा करने वाले किसी भी लोकप्रिय ब्लॉग या लेख?

Answer 1

मेरे पास कोई संदर्भ नहीं है, लेकिन यहां मेरे विचार पुस्तकालय के संभावित उपयोगकर्ता के रूप में हैं।

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

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

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

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

Answer 2

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

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

दोनों मामलों में कुंजी लाइब्रेरी के दस्तावेज़ीकरण और त्रुटि संदेशों (या तो अनुपलब्ध सेटिंग्स या विवादित लोगों के लिए) में पर्याप्त जानकारी प्रदान करना है कि उपयोगकर्ता यह पता लगा सकता है कि उन सेटिंग्स का वास्तव में क्या मतलब है/नियंत्रण नहीं है पुस्तकालय के स्रोत कोड के माध्यम से पढ़ें।यह हिस्सा कठिन है क्योंकि 1) यह लाइब्रेरी डेवलपर के दृष्टिकोण से हमें थकाऊ है (इसलिए इसे अक्सर स्किम किया जाता है) और 2) प्रलेखन को नौसिखिया की मानसिकता से लाइब्रेरी में लिखा जाना चाहिए, जो अक्सर अलग होता है लाइब्रेरी डेवलपर की मानसिकता से - बाद में अंतर्निहित कनेक्शन/प्रभावों को जानता है, पूर्व को समझने योग्य तरीके से उन लोगों के बारे में बताया जाना चाहिए।

Answer 3

हालांकि समस्या डोमेन के संदर्भ में बिल्कुल समान नहीं है, यह मुझे Convention over Configuration तर्क के रूप में मारता है।

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

मुझे हंसेलमैन के पॉडकास्ट पसंद हैं, इसलिए यदि आप थोड़ा हल्का सुनना चाहते हैं, तो this podcast देखें।

Answer 4

मुझे लगता है कि आपके प्रश्न को कुछ स्पष्टीकरण की आवश्यकता है। शुरुआत करने वालों के लिए, मुझे नहीं लगता कि पुस्तकालय में कोई रनटाइम कॉन्फ़िगरेशन होना चाहिए। निर्भरताओं के संदर्भ में, लाइब्रेरी निर्भरताओं को उस पर्यावरण के लिए उपयुक्त तरीके से संभाला जाना चाहिए जिसके लिए उन्हें लिखा जा रहा है। पायथन में, उन निर्भरताओं को setup.py फ़ाइल (आवश्यकताओं के तहत) में होना चाहिए, और आखिरकार उस फ़ाइल को जो भी सेवा आप उपलब्ध कराने पर योजना बनाते हैं, उसे प्राप्त करना चाहिए (यानी पायथन के लिए pypi)।

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

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