कोड और डेटा का पृथक्करण कैसे एक अभ्यास बन गया?

Question

कृपया प्रश्न को ध्यान से पढ़ें: यह पूछता है कि कैसे , क्यों नहीं ।

मैं हाल ही में इस उत्तर पर आया था , जो अपरिवर्तनीय डेटा संग्रहीत करने के लिए डेटाबेस का उपयोग करने का सुझाव देता है:

ऐसा लगता है कि आपके द्वारा वर्णित कई जादुई संख्याएं - विशेष रूप से यदि वे भाग पर निर्भर हैं - वास्तव में डेटा हैं, कोड नहीं। [...] इसका मतलब एक SQL प्रकार डेटाबेस हो सकता है, या इसका मतलब केवल एक स्वरूपित पाठ फ़ाइल हो सकता है।

यह मुझे प्रतीत होगा कि यदि आपके पास वह डेटा है जो आपके प्रोग्राम का हिस्सा है, तो ऐसा करने की चीज उसे प्रोग्राम में डालना है । उदाहरण के लिए, यदि आपके कार्यक्रम का कार्य स्वरों की गणना करना है, तो इसमें गलत क्या vowels = "aeiou"है? आखिरकार, अधिकांश भाषाओं में डेटा संरचनाएं हैं जो इस उपयोग के लिए सटीक रूप से डिज़ाइन की गई हैं। जैसा कि ऊपर सुझाया गया है, आप इसे "स्वरूपित पाठ फ़ाइल" में डालकर अलग-अलग डेटा को क्यों परेशान करेंगे? क्यों नहीं बस उस पाठ फ़ाइल को आपकी पसंद की प्रोग्रामिंग भाषा में स्वरूपित किया गया है? अब यह एक डेटाबेस है? या यह कोड है?

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

उदाहरण के लिए, इस लेख: कठपुतली कोड से डेटा को अलग करने की समस्या । समस्या ? क्या समस्या है? यदि कठपुतली मेरे बुनियादी ढांचे का वर्णन करने के लिए एक भाषा है, तो यह भी क्यों नहीं बताया जा सकता है कि नामांकित व्यक्ति 8.8.8.8 है? यह मुझे लगता है कि समस्या यह नहीं है कि कोड और डेटा मिंगल हैं, ¹ लेकिन कठपुतली में पर्याप्त समृद्ध डेटा संरचनाओं और अन्य चीजों के लिए इंटरफ़ेस करने के तरीके का अभाव है।

मुझे यह शिफ्ट परेशान लगता है। ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग ने कहा कि "हम मनमाने ढंग से समृद्ध डेटा संरचनाओं को चाहते हैं", और इसलिए कोड की शक्तियों के साथ डेटा संरचनाएं संपन्न हैं। परिणामस्वरूप आपको एनकैप्सुलेशन और एब्स्ट्रेक्शन मिलता है। यहां तक ​​कि SQL डेटाबेस में संग्रहीत कार्यविधियाँ हैं। जब आप YAML या पाठ फ़ाइलों या डंब डेटाबेस में डेटा को अनुक्रमित करते हैं जैसे कि आप कोड से एक ट्यूमर निकाल रहे हैं, तो आप वह सब खो देते हैं।

क्या कोई समझा सकता है कि कोड से डेटा को अलग करने का यह अभ्यास कैसे हुआ, और यह कहां जा रहा है? क्या कोई प्रकाशकों द्वारा प्रकाशनों का हवाला दे सकता है, या कुछ प्रासंगिक डेटा प्रदान कर सकता है जो एक उभरती हुई आज्ञा के रूप में "डेटा से अलग कोड" को प्रदर्शित करता है, और इसके मूल को दिखाता है?

^{1: अगर कोई ऐसे भेद भी कर सकता है। मैं आपको देख रहा हूं, लिस्प प्रोग्रामर।}

Comments

अपनी पसंद की भाषा में html और css के सभी को दफनाने के लिए स्वतंत्र महसूस करें।

— जेएफओ

मुझे लगता है कि उद्धरण के लेखक का मतलब यह है कि जादू संख्या वास्तव में अपरिवर्तनीय नहीं हैं।

— पीटर बी

स्वरों की हार्ड-कोडिंग में कुछ भी गलत नहीं है। यदि आपके आवेदन का उपयोग केवल अंग्रेजी में स्वरों को गिनने के लिए किया जाएगा।

— माइकल पॉलुकोनिस

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

— user16764

@MichaelPaulukonis: और इसे डेटाबेस में रखना एक नकली समाधान है। डच के लिए आवश्यक परिवर्तन? शून्य (एक DB परिवर्तन भी नहीं)। फ्रेंच / जर्मन के लिए आवश्यक परिवर्तन? कम से कम ISO-8859-1 समर्थन करते हैं। (DB से अधिक)। ग्रीक / रूसी के लिए आवश्यक परिवर्तन? यूनिकोड समर्थन (डीबी से अधिक)। वास्तव में, मैं किसी भी भाषा के बारे में नहीं सोच सकता जहाँ डीबी किसी भी मदद की हो।

— 11

Answer 1

कोड से डेटा को अलग करने के कई अच्छे कारण हैं, और कुछ कारण नहीं। निम्नलिखित मन में आते हैं।

समयबद्धता। डेटा मूल्य कब जाना जाता है? क्या यह उस समय कोड लिखा जाता है, जब इसे संकलित किया जाता है, लिंक किया जाता है, जारी किया जाता है, लाइसेंस दिया जाता है, कॉन्फ़िगर किया जाता है, निष्पादन शुरू किया जाता है या दौड़ते समय। उदाहरण के लिए, एक सप्ताह (7) में दिनों की संख्या प्रारंभिक रूप से ज्ञात है, लेकिन USD / AUD विनिमय दर काफी देर से ज्ञात होगी।

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

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

चिंताओ का विभाजन। सही ढंग से काम करने के लिए एल्गोरिदम प्राप्त करना सबसे अच्छा विचार है कि डेटा मूल्यों का उपयोग करने से अलग किया जाता है। एल्गोरिदम का परीक्षण करने के लिए डेटा की आवश्यकता होती है, उनका हिस्सा बनने के लिए नहीं। Http://c2.com/cgi/wiki?ZeroOneInfinityRule भी देखें ।

आपके सवाल के जवाब में यह कोई नई बात नहीं है। मूल सिद्धांत 30 से अधिक वर्षों में नहीं बदले हैं, और उस समय के बारे में बार-बार लिखा गया है। मैं इस विषय पर कोई बड़ा प्रकाशन याद नहीं कर सकता क्योंकि यह आमतौर पर विवादास्पद नहीं माना जाता है, बस नए लोगों को समझाने के लिए कुछ। यहाँ कुछ और है: http://c2.com/cgi/wiki?SeparationOfDataAndCode ।

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

रुझानों के अनुसार, मैंने पेशेवर प्रोग्रामर (10+ वर्ष) के बीच रवैये में कोई बड़ा बदलाव नहीं देखा है, लेकिन उद्योग तेजी से युवाओं से भरा हुआ है और मुझे लगता है कि बहुत सी चीजें ज्ञात थीं और निर्णय लिया गया था कि वे कभी-कभी नए से बाहर हो जाते हैं। अंतर्दृष्टि लेकिन कभी-कभी अज्ञानता से बाहर।

Comments

क्या आप इस अभ्यास के इतिहास और प्रवृत्ति पर विस्तार कर सकते हैं? यदि सभी ने ये विचार दिए, तो मैंने सवाल नहीं पूछा। प्रश्न का आधार यह है कि लोग ध्यान से विचार नहीं कर रहे हैं कि उनका डेटा कहां जाना चाहिए (संकलित स्थिरांक, बाहरी डेटाबेस, YAML ...), लेकिन वे केवल "कॉड और डेटा मिक्सड बैड! हकल SMASH!" ऐसा क्यों या कब हुआ?

— फिल फ्रॉस्ट

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

— david.pfx

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

— फिल फ्रॉस्ट

आपको हमेशा "_____ BAD! HULK SMASH!" - इसका मतलब यह नहीं है कि यह सच है। अक्सर इस तरह की चीज (उदाहरण के लिए "" GOTO 'BAD! HULK SMASH! ") को शुरुआती लोगों को यह सिखाया जाता है कि उन्हें क्यों, या अपवाद क्या हैं।

— AMADANON इंक।

Localityरिवर्स में भी काम करता है: हमने अलग-अलग ग्राहकों के लिए कस्टम आवश्यकताओं के कारण एक सॉर्ट-प्रकार-प्रकार प्रणाली के साथ समाप्त किया, और कई वर्षों के परीक्षण और त्रुटि के माध्यम से अपने स्थिरांक (यहां तक ​​कि तालिकाओं, डिकोट्स की सूचियों के माध्यम से) को बाहर रखना सीखा डेटाबेस और कोड में। दोनों क्योंकि "प्लगइन" के अलावा कहीं भी इसका उपयोग करना गलत है, और क्योंकि परिवर्तन होने पर परिवर्तन स्वचालित रूप से होते हैं।

— इज़्काता

Answer 2

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

अनुमतियाँ

यदि डेटा हार्ड-कोडेड है, तो आपको उस डेटा को संपादित करने के लिए स्रोत फ़ाइल को संपादित करने की आवश्यकता होगी। इसका मतलब है कि या तो:

• केवल डेवलपर्स डेटा संपादित कर सकते हैं। यह खराब है - डेटा प्रविष्टि ऐसी चीज नहीं है जिसके लिए डेवलपर के कौशल और ज्ञान की आवश्यकता होती है।

• गैर-डेवलपर्स स्रोत फ़ाइल को संपादित कर सकते हैं। यह बुरा है - वे स्रोत फ़ाइल को बिना जाने भी पेंच कर सकते हैं!

• डेटा को अलग-अलग स्रोत फ़ाइलों में हार्ड-कोड किया गया है, और गैर-डेवलपर्स के पास केवल उन फ़ाइलों तक पहुंच है। लेकिन यह वास्तव में गिनती नहीं है - अब डेटा को कोड से अलग किया गया है और इसे अपनी फ़ाइलों में संग्रहीत किया गया है ...

संपादन

इसलिए, डेटा को कौन संपादित कर सकता है , इसके बारे में इसे अलग से संग्रहीत करना सबसे अच्छा है। कैसे के बारे में कैसे वे डेटा को संपादित करेंगे? यदि आपके पास बहुत अधिक डेटा है, तो इसे हाथ से लिखना थकाऊ और त्रुटि-प्रधान है। इसके लिए कुछ UI होना ज्यादा बेहतर है! यहां तक ​​कि अगर आपको अभी भी सब कुछ लिखना है, तो आपको प्रारूप के बॉयलर-प्लेट को टाइप नहीं करना होगा, इसलिए कम संभावना है कि आप प्रारूप को गड़बड़ कर देंगे और पूरी फाइल को पेंच कर देंगे!

यदि डेटा हार्ड कोडित है, तो उस UI को बनाने का मतलब होगा कि एक स्वचालित टूल आपको हाथ से लिखी गई स्रोत फ़ाइलों को संपादित करेगा। उस सिंक को अंदर आने दें, एक स्वचालित टूल आपकी स्रोत फ़ाइलों को खोलेगा, यह पता लगाने का प्रयास करेगा कि डेटा कहाँ होना चाहिए, और उस कोड को संशोधित करें। Brrr ... Microsoft ने उन चीजों से बचने के लिए C # को आंशिक कक्षाएं शुरू कीं ...

यदि डेटा अलग है, तो आपके स्वचालित उपकरण को बस डेटाफ़ाइल्स को संपादित करना होगा। मैं बल्कि यह मानता हूं कि डेटाफाइल्स के संपादन वाले कंप्यूटर प्रोग्राम आजकल असामान्य नहीं हैं ...

स्केलिंग

कोड और डेटा स्केल बहुत अलग तरीके से। जैसे-जैसे आपका कोड बढ़ता है, आप इसे और अधिक वर्गों और विधियों (या डेटा संरचनाओं और कार्यों) में अलग करना चाहते हैं, लेकिन आपका डेटा - चाहे वह कितना भी बढ़ता हो - आप एक जगह पर रखना चाहते हैं। यहां तक ​​कि अगर आपको इसे कई फ़ाइलों में अलग करना है, तो आप उन फ़ाइलों को किसी भी तरह से बंडल करना चाहते हैं, इसलिए कोड से उस डेटा तक पहुंचना आसान होगा।

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

खोज कर

आपके पास टन डेटा है - यह केवल प्राकृतिक है जिसे आप इसके माध्यम से खोजना चाहते हैं।

• यदि आप इसे डेटाबेस में संग्रहीत करते हैं - आप डेटाबेस क्वेरी भाषा का उपयोग कर सकते हैं।

• यदि आप इसे एक XML फ़ाइल में संग्रहीत करते हैं - तो आप XPath का उपयोग कर सकते हैं।

• यदि आप इसे JSON / YAML में संग्रहीत करते हैं - तो आप इसे अपनी पसंदीदा स्क्रिप्टिंग भाषा की REPL में लोड कर सकते हैं और इसे खोज सकते हैं।

• यहां तक ​​कि अगर आप इसे सादे पुरानी पाठ फ़ाइल में संग्रहीत करते हैं, क्योंकि इसमें एक संरचना है, तो आपका कार्यक्रम यह पहचान सकता है कि आप इसे खोजने के लिए grep / sed / awk का उपयोग कर सकते हैं।

हालांकि यह सच है कि आप स्रोत फ़ाइल में हार्ड कोडित डेटा के माध्यम से grep / sed / awk भी कर सकते हैं, यह भी काम नहीं करता है, क्योंकि आपकी क्वेरी अन्य, गैर-संबंधित लाइनों, या मिस लाइनों के साथ मेल खा सकती है जो अलग-अलग लिखे गए थे क्योंकि प्रोग्रामिंग भाषा का डेटा प्रतिनिधित्व सिंटैक्स इसकी अनुमति देता है।

कोड के माध्यम से खोज करने के लिए उपकरण हैं, लेकिन वे घोषणाओं को खोजने के लिए अच्छे हैं, न कि हार्ड कोडित डेटा के लिए।

ऐसा कहे जाने के बाद...

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

मेरे पास एक वर्ग था जब हमारे पास "जादू नंबर" के बारे में बहुत सख्त नियम थे - हमारे कोड में कोई संख्या नहीं हो सकती थी। इसका मतलब है कि हमें ऐसा करना होगा:

#define THE_NUMBER_ZERO 0
//....
for(int i=THE_NUMBER_ZERO;i<cout;++i){
//....

जो एकमुश्त हास्यास्पद है! हां, 0तकनीकी रूप से "डेटा" है, लेकिन यह कोड के हिस्से के रूप में बाकी forलूप है! इसलिए भले ही हम इसे डेटा के रूप में प्रस्तुत कर सकते हैं और इसे कोड से अलग कर सकते हैं , लेकिन इसका मतलब यह नहीं है कि हमें चाहिए । इसलिए नहीं कि हम डेटा को कोड के अंदर छोड़ना चाहते हैं, बल्कि इसलिए कि यह वास्तव में डेटा नहीं है - बाकी कोड से अधिक नहीं, जो कि लोगों और शून्य के लिए भी संकलित है ...

Answer 3

मुझे लगता है कि कुछ भ्रम चल रहा है। आप दो चीजों को एक साथ मिला रहे हैं: "कोड और डेटा को अलग करना" और "प्रोग्राम के व्यवहार को डेटा के रूप में व्यक्त करना"।

आपके मामले में, आप वास्तव में दूसरे के बारे में चिंतित हैं और इसमें पहले को मिलाते हैं। जब आप प्रोग्राम के व्यवहार को डेटा के रूप में व्यक्त करते हैं तो इसे विस्तारित करना आसान हो जाता है। आपके उदाहरण में vowels = "aeiou", फिर नया स्वर जोड़ना उतना ही सरल है जितना कि एक चरित्र जोड़ना। यदि आपके पास यह डेटा बाहरी रूप से है, तो आप प्रोग्राम को फिर से शुरू किए बिना इस व्यवहार को बदल सकते हैं।

और जब आप इसके बारे में सोचते हैं, तो OOP इस सोच का विस्तार है। डेटा और व्यवहार को एक साथ बांधने से आप प्रोग्राम के डेटा के आधार पर प्रोग्राम के व्यवहार को बदल सकते हैं।

Comments

स्वाभाविक रूप से, स्वरों की सूची बदलने वाली है।

— cHao

@ cHao जैसे ही i18n में कदम है, यह है।

— मोनिका

i18n आपके सिर को तोड़ सकता है - जावा में कुछ विकृत उदाहरण देखें javaspecialists.eu/archive/Issue209.html

— रोरी हंटर

@Angew: जैसे ही i18n में कदम रखा जाता है, वैसे भी , आप वैसे भी खराब हैं । इसके लिए आपको कोड की आवश्यकता है; भोला समाधान अंग्रेजी में भी हर मामले को संभालने में असमर्थ है। (भूल जाओ ïएक पल के लिए, के बारे में आइए बात करते हैं yऔर w!) एक डेटाबेस के लिए सूची बाहर ले जा रहा है कि ठीक करने के लिए नहीं जा रहा है, और वास्तव में हानिकारक है - यह की जटिलता है कि बेकार अगर किया गलत होगा, लेकिन आप यह नहीं करेंगे यहां तक ​​कि पता है कि "गलत" क्या है जब तक आप जमीन से i18n के लिए डिज़ाइन नहीं कर रहे हैं। जिस बिंदु पर आप पहले से ही महसूस कर रहे हैं कि स्वरों की एक सूची वैसे भी इसे काटने नहीं जा रही है।

— cHao

@ बेन: मैं वास्तव में थोड़ा आश्चर्यचकित नहीं होऊंगा। मैं वर्तमान में कुछ कोड बदलने पर काम कर रहा हूं जैसे कि हम बोलते हैं। लेकिन डेटाबेस के लिए सब कुछ आउटसोर्सिंग एक पूरी तरह से दूसरे का भाग्य-बता रहा है। यदि आप पहले से नहीं जानते हैं कि क्या कुछ को संशोधित करने की आवश्यकता होगी - और इससे भी महत्वपूर्ण बात, यदि आप अभी तक नहीं जानते हैं कि इसे कैसे संशोधित करने की आवश्यकता होगी - तो IMO यह बेहतर है कि आप इसे जोड़ने से पहले उस लचीलेपन की ज़रूरत है ।

— cHao

Answer 4

उदाहरण के लिए, यदि आपके कार्यक्रम का कार्य स्वरों की गणना करना है, तो इसमें स्वर = "अईउउ" होने में क्या गलत है?

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

आप स्वरों का उल्लेख करते हैं = "aeiou", क्या होगा अगर मैं कभी-कभी "y" चाहता हूं, तो क्या मुझे पूरे कार्यक्रम का पुनर्निर्माण करना चाहिए? क्या अब मैं संस्करणों को आसानी से अपग्रेड कर सकता हूं कि मैंने कोड को संशोधित किया है? यदि कोई त्रुटि है, तो क्या मैं इसका कारण बना, या क्या कार्यक्रम टूट गया है?

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

जब आप YAML या पाठ फ़ाइलों या डंब डेटाबेस में डेटा को अनुक्रमित करते हैं जैसे कि आप कोड से एक ट्यूमर निकाल रहे हैं

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

Comments

Torvalds उद्धरण डेटा संरचनाओं को संदर्भित करता है, डेटा को नहीं।

— user949300

ओपी कहता है: "ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग ने कहा" हम मनमाने ढंग से समृद्ध डेटा संरचनाओं को चाहते हैं ", और इसलिए कोड की शक्तियों के साथ डेटा संरचनाओं को संपन्न किया।"

— FMJaguar

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

— सोरू

टोरवाल्ड्स बोली के लिए +1। मैं इस भावना से सहमत हूं: कठपुतली के उदाहरण में, मुझे लगता है कि मुद्दा यह है कि कठपुतली के पास एक अच्छी डेटा संरचना नहीं है कि लोग इसमें जो जानकारी डालना चाहते हैं उसका प्रतिनिधित्व कर सकें। डेटा संरचनाओं को ठीक करने के बजाय, कठपुतली डेवलपर्स ने कहा कि "कोड में डेटा" समस्या है (क्यों? यही सवाल है!) और विकसित हिरा , जिसे मैं समस्या को कहीं और स्थानांतरित करने की तुलना में थोड़ा अधिक देखता हूं, और इसके अलावा असंभव बना रहा हूं। व्यवहार को डेटा से जोड़ना।

— फिल फ्रॉस्ट

Answer 5

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

अब, मुझे अभी भी लगता है कि यह एक मूर्खतापूर्ण निर्णय था, और अगर हमारे पास हाथ पर बुनियादी ढांचा नहीं था , तो मैंने इसे पूरा नहीं किया।

लेकिन मेरे पक्ष में कुछ तर्क हैं:

• यदि आपके पास एक डेटाबेस मानसिकता है, तो SQL डेटाबेस में संदर्भ डेटा डालने से आप रिपोर्टिंग के लिए उस पर शामिल हो सकते हैं।
• यदि आपके पास एक व्यवस्थापक उपयोगिता है, या डेटाबेस तक पहुंच है, तो आप रनटाइम पर मानों को घुमा सकते हैं। (हालांकि वह आग से खेल सकता है।)

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

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

Comments

दुकान प्रक्रियाओं के बारे में अच्छी टिप्पणी, जहां XML का संपादन "ठीक" है, लेकिन कोड में एक ही चीज को संपादित करना एक बड़ी परेशानी है।

— user949300

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

— jwenting

यह हमेशा मूर्खतापूर्ण लगता है, एक दिन, कोई पूछता है "क्या हम इसे उपयोगकर्ता एक्स के लिए फिर से कॉन्फ़िगर कर सकते हैं जो इसे मांग रहा है", और फिर यह सब के बाद इतना मूर्खतापूर्ण नहीं लगता है। धिक्कार है ग्राहक :)

— gbjbaanb

... और अगर वह दिन "कभी नहीं" है, तो वह लंबे समय तक मूर्खतापूर्ण महसूस कर रहा है

— रोब

Answer 6

मुझे आपसे एक पूरी तरह से गंभीर सवाल पूछना है: क्या, आपके विचार में, "डेटा" और "कोड" के बीच अंतर है?

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

डेटा का प्रकार अनुप्रयोग द्वारा भिन्न होता है; एक वाणिज्यिक चालान प्रणाली एक SQL डेटाबेस में ग्राहक को स्टोर कर सकती है और सूचना को ऑर्डर कर सकती है, और एक वेक्टर-ग्राफिक्स प्रोग्राम एक बाइनरी फ़ाइल में जियोमेट्री डेटा और मेटाडेटा स्टोर कर सकता है। इन दोनों मामलों में और बीच में सब कुछ, कोड और डेटा के बीच एक स्पष्ट और अटूट अलगाव है। डेटा उपयोगकर्ता का है , प्रोग्रामर का नहीं, इसलिए इसे कभी भी हार्ड-कोड नहीं किया जा सकता है।

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

यहां तक ​​कि यह परिभाषा, जो केवल "डेटा" शब्द की तुलना में काफी कम अस्पष्ट है, में कुछ समस्याएं हैं। उदाहरण के लिए, क्या होगा यदि कार्यक्रम के महत्वपूर्ण भाग प्रत्येक अलग-अलग भाषाओं में लिखे गए हों? मैंने व्यक्तिगत रूप से कई परियोजनाओं पर काम किया है जो लगभग 50% सी # और 50% जावास्क्रिप्ट हैं। जावास्क्रिप्ट कोड "डेटा" है? ज्यादातर लोग कहेंगे ना। HTML के बारे में क्या है, वह "डेटा" है? ज्यादातर लोग अभी भी नहीं कहेंगे।

CSS के बारे में क्या? क्या वह डेटा या कोड है? अगर हम कोड के बारे में कुछ ऐसा सोचते हैं जो प्रोग्राम व्यवहार को नियंत्रित करता है, तो CSS वास्तव में कोड नहीं है, क्योंकि यह केवल (अच्छी तरह से, ज्यादातर) उपस्थिति को प्रभावित करता है, व्यवहार को नहीं। लेकिन यह वास्तव में डेटा नहीं है; उपयोगकर्ता इसका मालिक नहीं है, एप्लिकेशन वास्तव में इसका मालिक भी नहीं है। यह UI डिज़ाइनर के लिए कोड के बराबर है। यह कोड की तरह है , लेकिन काफी कोड नहीं है।

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

क्या आप निम्न प्रारूप को पहचानते हैं?

{
    name: 'Jane Doe',
    age: 27,
    interests: ['cats', 'shoes']
}

मुझे यकीन है कि ज्यादातर लोग करते हैं; यह JSON है । और यहां JSON के बारे में दिलचस्प बात है: जावास्क्रिप्ट में, यह स्पष्ट रूप से कोड है, और हर दूसरी भाषा में, यह स्पष्ट रूप से स्वरूपित डेटा है। लगभग हर एक मुख्यधारा की प्रोग्रामिंग भाषा में JSON "पार्सिंग" के लिए कम से कम एक पुस्तकालय है।

यदि हम जावास्क्रिप्ट फ़ाइल में किसी फ़ंक्शन के अंदर उसी सटीक सिंटैक्स का उपयोग करते हैं, तो यह संभवतः कोड के अलावा और कुछ नहीं हो सकता है। और फिर भी, अगर हम उस JSON को लेते हैं, तो इसे एक .jsonफ़ाइल में बंद करें, और इसे जावा एप्लिकेशन में पार्स करें, अचानक यह "डेटा" है। क्या यह वास्तव में समझ में आता है?

मेरा तर्क है कि "डेटा-नेस" या "कॉन्फ़िगरेशन-नेस" या "कोड-नेस" जो वर्णित किया जा रहा है, उसके लिए अंतर्निहित है , न कि इसका वर्णन कैसे किया जा रहा है।

यदि आपके प्रोग्राम को यादृच्छिक पासफ़्रेज़ उत्पन्न करने, कहने, करने के लिए 1 मिलियन शब्दों के शब्दकोश की आवश्यकता है, तो क्या आप इस तरह से कोड करना चाहते हैं:

var words = new List<string>();
words.Add("aa");
words.Add("aah");
words.Add("ahhed");
// snip 172836 more lines
words.Add("zyzzyva");
words.Add("zyzzyvas");

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

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

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

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

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

इसलिए, संक्षेप में:

• "कोड" एक कठोर परिभाषित शब्द नहीं है। यदि आप अपनी परिभाषा को डोमेन-विशिष्ट भाषाओं और कुछ और जो व्यवहार को प्रभावित करते हैं, को शामिल करने के लिए विस्तारित करते हैं, तो इस स्पष्ट घर्षण का एक बहुत ही बस गायब हो जाएगा और यह सब समझ में आएगा। आप एक फ्लैट फ़ाइल में गैर-संकलित, डीएसएल "कोड" रख सकते हैं।

• "डेटा" का तात्पर्य ऐसी जानकारी से है जो उपयोगकर्ता (ओं) के पास है या डेवलपर्स के अलावा किसी और के पास है, और आमतौर पर डिजाइन समय पर उपलब्ध नहीं है। यदि आप ऐसा करना चाहते हैं तो भी यह कठिन-कूटबद्ध नहीं हो सकता है। स्व-संशोधित कोड के संभावित अपवाद के साथ , कोड और डेटा के बीच अलगाव परिभाषा की बात है, न कि व्यक्तिगत प्राथमिकता की।

• "सॉफ्ट-कोडिंग" एक भयानक अभ्यास हो सकता है जब ओवर-एप्लाइड किया जाता है, लेकिन जरूरी नहीं कि बाहरीकरण के प्रत्येक उदाहरण में सॉफ्ट-कोडिंग का गठन हो, और "फ्लैट फाइलों" में सूचनाओं के भंडारण के कई उदाहरण जरूरी नहीं हैं कि बाहरीकरण पर एक बॉर्न फाइड प्रयास हो।

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

Answer 7

मेरा सुझाव है कि इस क्लासिक लेख को ओरेन एनी (उर्फ आयेंडे रहियन) पढ़ें

http://ayende.com/blog/3545/enabling-change-by-hard-coding-everything-the-smart-way

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

इस तरह से आप संभावित रूप से पार्सिंग / इंटरप्रिटेशन की जटिलताओं से बचते हैं ("लेकिन कोई और मेरे YAML / JSON को पार्स करता है" - विशिष्ट एपीआई कॉल में पार्स किए गए टेक्स्ट की मैपिंग, इंटरप्रेटिंग का एक रूप हो सकता है), और "डेटा के बीच दूसरे चरण की जटिलता से बचें।" ”और उसका उपयोग।

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

Answer 8

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

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

उस बिंदु तक, हमारे पास दो तर्क (कॉर्पस और गिने जाने वाले अक्षर) के साथ एक फ़ंक्शन है। हम केवल एक सामान्य रूप से सामान्य "प्रकार" या "वर्ग" खोजने के लिए चिंतित हैं पत्र भी संबंधित हैं: हम निश्चित रूप से ASCII प्रतीकों से बेहतर कर सकते हैं!

"सामान्यीकरण और पुन: प्रयोज्यता" को दर्शाने वाला एक दानव दर्ज करें -dogma: - उस वर्ग के इनपुट स्ट्रीम में किसी भी वर्ग के किसी भी प्रतीक की गणना क्यों नहीं की जाती है? (अक्षरों से लेकर मनमाने ढंग से लेकिन परिमित लंबाई के अक्षरों तक सार जो कि आप कंप्यूटर के साथ प्राप्त कर सकते हैं सबसे सामान्य है ...) - रुको, फिर भी हम अभी भी प्राकृतिक संख्याओं में गिने जा रहे हैं। हालाँकि गिनती को सामान्य माना जा सकता है, क्योंकि मुहावरों को पूरा करने के लिए एक गणनीय सेट से एक मैपिंग के रूप में ... [आपको विचार मिलता है]

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

"डेटा" और "कोड" का विभाजन संभवतया तुच्छ (फ़ंक्शन तर्क) होगा या आप स्वयं को हमलावरों को चर ("डेटा") के रूप में मानेंगे।

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

आपकी विशिष्ट समस्या के लिए: यदि आप 1.) अपने विशिष्ट मामले के लिए अधिकतम हार्ड-कोडिंग के साथ एक प्रोग्राम लिख सकते हैं और फिर 2.) जैसे कि सीधे उस तरीके से कोड को सामान्य करें। अधिक फ़ंक्शन तर्क पेश करना और अन्य "तुच्छ पैटर्न" का उपयोग करके आप यह सुनिश्चित कर सकते हैं कि आप कोड और डेटा को अलग कर रहे हैं, स्पष्ट तरीका, जैसे कि कार्यात्मक प्रोग्रामिंग का आविष्कार किया गया था। (ofc आप को छोड़ कर १। और २ करें। तुरन्त ...)

यहां कुछ भी स्पष्ट नहीं होने की संभावना "सिद्धांत-गतिरोध" का मामला है: जैसे कि इंटरफ़ेस को संदर्भित करने वाला एक इंटरफ़ेस लिखना और फिर भी एक और हस्तक्षेप ... और अंत में आपके पास इन सभी इंटरफेस को कॉन्फ़िगर करने के लिए एक साफ सा xml-file है और आपके वर्ग-इंटरफ़ेस-अव्यवस्था में इंजेक्ट की जाने वाली निर्भरताएँ।

बस उम्मीद है, आप तो xml- पार्सर की आवश्यकता है काम करने के लिए एक xml- विन्यास की आवश्यकता नहीं है ...