"विन्यास पर सम्मेलन" बुनियादी प्रोग्रामिंग सिद्धांतों का उल्लंघन नहीं है?

Question

मैं WPF MVVM ढांचे Caliburn.Micro को देख रहा था और पढ़ा कि बहुत सी मानक चीजें नामकरण परंपराओं पर आधारित हैं ।

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

संपादित करें:

तो इस दृष्टिकोण को कॉन्फ़िगरेशन पर कन्वेंशन कहा जाता है। चूँकि मुझे इससे संबंधित कोई प्रश्न नहीं मिला, इसलिए मैंने अपना प्रश्न बदल दिया:

मेरा सवाल यह है कि:

क्या विन्यास पर सम्मेलन चीजों को सरल बनाने का एक सही तरीका है, या क्या यह कुछ प्रोग्रामिंग सिद्धांतों (और यदि ऐसा है, तो कौन से) का उल्लंघन कर रहा है?

Comments

अधिकांश दृष्टिकोण / सिद्धांत कुछ हद तक कुछ अन्य दृष्टिकोण / सिद्धांतों का उल्लंघन करते हैं। यह ज्यादातर प्राथमिकताओं और व्यापार-नापसंद का मामला है।

— जोकिम सॉर

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

— गीर्टेन

सॉफ्टवेयर ट्रैसेबिलिटी की अवधारणा यहां प्रासंगिक है। प्रोग्रामर grep जैसे उपकरणों पर भरोसा करते हैं, लेकिन उत्पन्न कोड के उपयोग का पता लगाने के लिए बेहतर उपकरण की आवश्यकता होती है। उदाहरण के लिए, टूल को यह अधिक स्पष्ट करना चाहिए कि सीएसएस वर्ग "उपयोगकर्ता-आईडी" जनरेट विधि getUserId () और टेबल कॉलम user_id से संबंधित है।

— मैक्नील

Answer 1

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

कॉन्फ़िगरेशन पर कन्वेंशन प्रोग्रामर को चीजों के बारे में निर्णय लेने की मात्रा को कम करने के बारे में है। कुछ चीजों के लिए यह स्पष्ट है - कोई भी ऐसी भाषा होने पर विचार नहीं करेगा जहां प्रकारों का पूंजीकरण एक ऐसी चीज है जिसे आपको अपने कार्यक्रम के शीर्ष पर घोषित करने की आवश्यकता है - लेकिन अन्य चीजों के लिए यह इतना स्पष्ट नहीं है।

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

ग्रहण प्लगइन्स लिखते समय प्रोग्रामर को किस स्थान पर भेजना है इसका एक अच्छा उदाहरण है। जब मैंने कभी नहीं देखा है एक प्लगइन को देखकर, मैं तुरंत इसके बारे में कई बातें जानता हूं। निर्भरता की सूची MANIFEST.MF में है, विस्तार बिंदु plugin.xml में हैं, स्रोत कोड "src" के तहत है, और इसी तरह। यदि ये चीजें प्रोग्रामर को परिभाषित करने के लिए थीं, तो हर एक ग्रहण प्लगइन अलग होगा, और कोड नेविगेशन बहुत अधिक कठिन होगा।

Comments

+1: सॉफ्टवेयर विकास पर्याप्त जटिल है क्योंकि यह है। यदि आप उन चीजों में जटिलता से बच सकते हैं जो आपके नियंत्रण में हैं, तो ऐसा करें। उन स्थानों के लिए जटिलता को बचाएं, जिनकी आपको बिल्कुल आवश्यकता है।

— स्क्रप्ट टीपी

अंतर और संतुलन के बारे में स्पष्ट स्पष्टीकरण के लिए धन्यवाद।

— जेरेतैन

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

— डेन

उदाहरणों को अधिक मत समझना, वे सिर्फ उदाहरण हैं। पहला एक सम्मेलन का एक उदाहरण है, अंतिम एक उदाहरण है जहां सम्मेलन एक अच्छी बात है। पर्ल उदाहरण एक उदाहरण है जहां बहुत अधिक सम्मेलनों (इम्प्लिट्स) एक बुरी चीज है (आईएमओ, मुझे जोड़ना चाहिए)।

— जेसपेरे

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

— एंडी

Answer 2

@JesperE को +1 दिया और कुछ जोड़ना पसंद किया:

क्या यह कुछ प्रोग्रामिंग सिद्धांतों का उल्लंघन कर रहा है

हां, "कॉन्फ़िगरेशन पर कन्वेंशन" सिद्धांत का उल्लंघन करता है "स्पष्ट रूप से निहित से बेहतर है" (उदाहरण के लिए, "ज़ेन-एंड-पायथन" पर एक नज़र डालें )।

दूसरी ओर, "सम्मेलन पर विपरीत" विन्यास "सरल जटिल से बेहतर है" का उल्लंघन करता है, और इससे भी बदतर, यह सूक्ष्म रूप से DRY सिद्धांत का उल्लंघन करता है , क्योंकि आपको अपने कोड में उपयोग किए गए नामों को भी आपके कॉन्फ़िगरेशन में दोहराना होगा। ।

Comments

इस सवाल का सबसे सीधा जवाब है!

— जोकिम सॉयर

यह दो सबसे अधिक उत्थान के बीच वास्तविक सही उत्तर है।

— डेन

+1 के लिए "स्पष्ट रूप से निहित से बेहतर है"

— जस्टिन ओम्स

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

— क्रिस क्रिचो

अच्छा उत्तर। @ क्रिस क्रिचो की टिप्पणी पर विस्तार करने के लिए, सॉफ्टवेयर मानकों या सिद्धांतों के बारे में अच्छी बात यह है कि आपके पास चुनने के लिए बहुत सारे हैं। :-)

— user949300

Answer 3

"विन्यास पर कुछ सम्मेलन" सिर्फ समझदार चूक के लिए उबलते हैं। गैर-मानक उद्देश्य के लिए इसका उपयोग करने के लिए आपको केवल कुछ कॉन्फ़िगर करना होगा। मुझे यहां स्ट्रट्स की तुलना रेल से करनी है। रेल में, आपको अपने "एक्शन / स्क्रीन" को एक फ़ोल्डर में रखना होगा और फिर वे बस काम करेंगे। स्ट्रट्स में, आपको उन्हें अभी भी एक फोल्डर में रखना है, लेकिन आपको एक्शन-नेम और जेएसपी फाइल और फॉर्म के नाम और फॉर्म बीन के साथ भी आना होगा और यह निर्दिष्ट करना होगा कि स्ट्रट्स-कॉन्फिगर में ये तीन चीजें एक साथ कैसे काम करती हैं। xml और निर्दिष्ट करें कि फॉर्म अनुरोध (RESTful) पर है। यदि वह पर्याप्त नहीं है, तो फ़ॉर्म / फॉर्म-बीन मैपिंग का स्ट्रट्स-कॉन्फ़िगर में अपना स्वयं का सेक्शन है जिसे बाद में उसी फ़ाइल में एक्शन सेक्शन में स्वतंत्र रूप से मैप किया जाता है और यह सब काम करने के लिए JSP फ़ाइल में हस्तलिखित स्ट्रिंग्स पर निर्भर करता है अच्छी तरह। प्रत्येक स्क्रीन के लिए, कम से कम 6 चीजें जो आपको नहीं करनी चाहिए और एक त्रुटि करने के कई अवसर हैं। मुझे लगता है कि यदि आप की जरूरत है तो आप उन सभी चीजों को मैन्युअल रूप से रेल में सबसे अधिक या सभी सेट कर सकते हैं, लेकिन स्ट्रट्स के विकास के समय के 2/3 को जटिलता की अनावश्यक परतों के निर्माण और रखरखाव में लिया जाता है।

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

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

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

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

Answer 4

दूसरे शब्दों में, एप्लिकेशन की कार्यक्षमता पूरी तरह से अपने कोड से नहीं बताई गई है, बल्कि फ्रेमवर्क के प्रलेखन द्वारा भी बताई गई है।

किसी एप्लिकेशन की कार्यक्षमता जो किसी फ्रेमवर्क का उपयोग करती है, हमेशा फ्रेमवर्क पर निर्भर होती है, कॉन्फ़िगरेशन पर कन्वेंशन उस संबंध में कोई फर्क नहीं पड़ता है।

मेरे अनुभव में, कॉन्फ़िगरेशन पर कन्वेंशन न केवल कोड को अधिक पठनीय बनाता है, बल्कि यह सूक्ष्म बग (विशेषकर कॉपी-पेस्ट-बग) को पेश करने की संभावना को भी कम करता है।

उदाहरण के लिए, आइए कुछ ढांचे A में FooBarमानें , ईवेंट कॉल को ट्रिगर करता है handleFooBar। एक अन्य फ्रेमवर्क बी में, यह सहसंबंध कहीं XMLfile में कॉन्फ़िगर किया गया है।

तो, ए में, यह बस है

handleFooBar() {
   ...
}

और जब तक आपने FooBar को मिस नहीं किया है, तब तक यह कहा जाएगा कि जब भी FooBar होता है।

बी में, यह फिर से है

handleFooBar() {
   ...
}

लेकिन

<eventconfiguration>
  <event>
    <type>FooBar</type>
    <handler>handleFooBar</handler>
  </event>
</eventconfiguration>

इस तरह से कॉन्फ़िगर करने के लिए सैकड़ों चीजों के साथ, यह सब बहुत आसान है जैसे आकस्मिक रूप से सूक्ष्म बग बनाना

<eventconfiguration>
  <event>
    <type>BarFoo</type>
    <handler>handleFooBar</handler>
  </event>
</eventconfiguration>

क्योंकि कॉपी-पेस्ट करने के बाद, हम केवल बदल <type>गए हैं लेकिन बदलना भूल गए हैं <handler>।

चूँकि वे कॉन्फ़िगरेशन फ़ाइलें बड़ी और नीरस हैं, इसलिए इसकी संभावना कम है कि कोई बग को प्रूफरीडिंग करके ढूंढेगा, क्योंकि वह वास्तविक प्रोग्राम कोड में एक समान बग ढूंढेगा।

Comments

+1: दोहराए, बोरिंग करने वाली लिखने, मुश्किल से पढ़ा है, लगभग-हमेशा स्पष्ट विन्यास से परहेज है सम्मेलन-ओवर-विन्यास का प्रमुख लाभ।

— जोआचिम साउर

Answer 5

यह कुछ सिद्धांतों का उल्लंघन हो सकता है, लेकिन साथ ही यह सबसे मौलिक डिजाइन सिद्धांतों में से एक का पालन करता है, एसआरपी (सिंगल रिस्पांसिबिलिटी प्रिंसिपल)।

Comments

सम्मेलनों का उपयोग करने का एकल जिम्मेदारी से कोई लेना-देना नहीं है। मैं एक सम्मेलन का उपयोग कर सकता हूं और इसमें 100 चीजें कर सकता हूं।

— सुमेरे