ज्ञान का पुन: उपयोग

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

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


एक ओर, यह हमें अधिक सचेत और विवेकपूर्ण तरीके से सूचना स्रोतों की पसंद से संबंधित बनाता है। और यह वह विचार था जिसने मुझे सामान्य रूप से प्रोग्रामिंग पर सबसे दिलचस्प पुस्तकों की एक सूची को संकलित करने के लिए प्रेरित किया, और अलग-अलग, सी # भाषा और .NET प्लेटफॉर्म पर सबसे महत्वपूर्ण किताबें । लेकिन जानकारी के उच्च-गुणवत्ता वाले स्रोतों के अलावा (ब्लॉग, पॉडकास्ट और वीडियो ट्यूटोरियल की सूची के साथ पुस्तकों की सूची को पूरक करना अच्छा होगा), किसी भी प्रोग्रामर का एक महत्वपूर्ण गुण संरचित और ज्ञान का "पुन: उपयोग" है।

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

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

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

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


अंश एक पदानुक्रम (*) बनाते हैं
(*) यह ग्रैडी बुच की पुस्तक "ऑब्जेक्ट-ओरिएंटेड एनालिसिस एंड डिज़ाइन विथ एप्लीकेशन एग्ज़ाम्पल्स" से एक ड्राइंग है।

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

डब्ल्यूसीएफ के उदाहरण पर ज्ञान का पुन: उपयोग

आइए WCF को एक उदाहरण के रूप में लेते हैं।


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

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

इसलिए, उदाहरण के लिए, यदि आपके पास .NET रीमोटिंग का अनुभव है, तो आप WCF पर स्विच करते समय इसका पुन: उपयोग कर सकते हैं: इनमें से प्रत्येक तकनीक एक "स्तरित" केक है, जिसमें विभिन्न स्तरों को कॉन्फ़िगर करने और कॉन्फ़िगर करने की क्षमता है। दोनों प्रौद्योगिकियों में, हम तात्कालिकता और प्रतिस्पर्धा के विभिन्न तरीकों का उपयोग कर सकते हैं, सुरक्षा को कॉन्फ़िगर कर सकते हैं और क्रमबद्धता का प्रबंधन कर सकते हैं।

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

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

नोट
एक बार जब मैंने इस सवाल का जवाब देने की कोशिश की, "WCF क्या है?" , यहां दिए गए ज्ञान के पुन: उपयोग की विधि का उपयोग करने की कोशिश की जा रही है और WCF रिसीवरों जैसे .NET रेमोटिंग और वेब सेवाओं के साथ अधिक से अधिक एनालॉग बनाए जा सकते हैं।

स्वचालित स्मृति प्रबंधन के उदाहरण पर ज्ञान का सामान्यीकरण

निम्न-स्तरीय बेस ब्लॉक के पदानुक्रम और पुन: उपयोग के अलावा, हम जटिलता से निपटने के लिए एक और ओओपी तंत्र का उपयोग कर सकते हैं: विरासत के माध्यम से सामान्यीकरण और विशेषज्ञता।

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

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

इसी तरह, एक काफी सामान्य स्थिति यह है कि जब वार्ताकार अपने अनुभव और ज्ञान को एक प्रोग्रामिंग भाषा के साथ अन्य परियोजनाओं और अन्य प्रोग्रामिंग भाषाओं में प्राप्त करता है। वास्तव में, वह इस ज्ञान को अपने ज्ञान के "आधार" वर्गों में सामान्य करता है, हालांकि इस समय इन वर्गों में केवल एक "वारिस" है:

Me: मुझे पता है कि कई विरासत कचरा है!
वह: क्यों?
मैं: क्योंकि यह जावा में नहीं है , लेकिन मैं अन्य भाषाओं को नहीं जानता!

यदि मैं जानता हूं कि एकमात्र भाषा जावा है, तो इस तरह के निष्कर्ष निकालना लापरवाह है। सबसे अधिक संभावना है, मैं अधिक सही निष्कर्ष निकालने में सक्षम हो सकता हूं और अपने ज्ञान को अधिक सचेत रूप से संरचना कर सकता हूं, कम से कम कई भाषाओं से परिचित हो सकता हूं जो कई विरासतों का समर्थन करते हैं, जैसे सी ++ और एफिल।

आइए, एक उदाहरण के रूप में, स्वचालित मेमोरी प्रबंधन के कई तरीकों पर विचार करें और उन्हें एक पदानुक्रमित रूप में प्रस्तुत करें।



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

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

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

निष्कर्ष

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