सही सॉफ्टवेयर अपघटन

पदानुक्रमित अपघटन

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

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

वस्तुओं का चयन करने से पहले, सिस्टम को कम से कम मानसिक रूप से बुनियादी सिमेंटिक ब्लॉकों में विभाजित करें। छोटे अनुप्रयोगों में, यह आमतौर पर करना बहुत आसान होता है: पदानुक्रम के कुछ स्तर काफी पर्याप्त होते हैं, क्योंकि सिस्टम को पहले सबसिस्टम / पैकेज में विभाजित किया जाता है, और पैकेज को कक्षाओं में विभाजित किया जाता है।

यह विचार उतना तुच्छ नहीं है जितना लगता है। उदाहरण के लिए, मॉडल-व्यू-कंट्रोलर (MVC) के रूप में इस तरह के एक सामान्य "आर्किटेक्चरल पैटर्न" का सार क्या है?

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

फिर यह पता चला है कि मॉड्यूल को किसी तरह से बातचीत करनी चाहिए, इसके लिए वे एक नियंत्रक जोड़ते हैं, जिसका काम मॉड्यूल की बातचीत को प्रबंधित करना है। एमवीसी के मोबाइल (क्लासिक) संस्करण में भी, ऑब्जर्वर पैटर्न को इसमें जोड़ा जाता है ताकि दृश्य मॉडल से घटनाओं को प्राप्त कर सके और वास्तविक समय में प्रदर्शित डेटा को बदल सके।

सबसे बड़े घटकों में सिस्टम के पहले विभाजन के परिणामस्वरूप प्राप्त विशिष्ट शीर्ष-स्तरीय मॉड्यूल ठीक हैं:

• व्यापार का तर्क;
• प्रयोक्ता इंटरफ़ेस;
• डेटाबेस;
• संदेश प्रणाली;
• ऑब्जेक्ट कंटेनर।

पहला विभाजन आमतौर पर पूरे एप्लिकेशन को 2-7 (अधिकतम 10 भागों) में विभाजित करता है। यदि हम इसे और अधिक भागों में तोड़ते हैं, तो उन्हें समूहित करने की इच्छा होगी, और हमें फिर से 2-7 शीर्ष-स्तरीय मॉड्यूल मिलेंगे।

कार्यात्मक अपघटन

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

प्रत्येक मॉड्यूल को कुछ उप-कार्यों को हल करने और उसके अनुरूप कार्य करने के लिए जिम्मेदार होना चाहिए । कार्यात्मक उद्देश्य के अलावा, मॉड्यूल को अपने कार्य को करने के लिए आवश्यक डेटा के एक सेट की भी विशेषता है, अर्थात:

मॉड्यूल = फ़ंक्शन + इसे निष्पादित करने के लिए आवश्यक डेटा।

यदि मॉड्यूल में अपघटन सही ढंग से किया जाता है, तो अन्य मॉड्यूल (अन्य कार्यों के लिए जिम्मेदार) के साथ सहभागिता न्यूनतम होगी। यह हो सकता है, लेकिन इसकी अनुपस्थिति आपके मॉड्यूल के लिए महत्वपूर्ण नहीं होनी चाहिए।

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

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

मजबूत और कमजोर कनेक्टिविटी

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

अपघटन की गुणवत्ता के लिए मुख्य मानदंड यह है कि कैसे मॉड्यूल अपने कार्यों को हल करने पर केंद्रित हैं और स्वतंत्र हैं।

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

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

सामंजस्य उस डिग्री की विशेषता है जिससे मॉड्यूल द्वारा किए गए कार्य एक दूसरे से संबंधित हैं।

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

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

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

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

यह माना जाता है कि अच्छी तरह से डिज़ाइन किए गए मॉड्यूल में निम्नलिखित गुण होने चाहिए:

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

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

वंशानुक्रम के बजाय रचना

अधिकांश प्रोग्रामर के लिए सक्षम अपघटन एक प्रकार की कला और एक कठिन कार्य है। सरलता यहाँ भ्रामक है, और गलतियाँ महंगी हैं।

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

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

सिस्टम को विघटित करते समय, अपने आप से प्रश्न पूछकर इसकी गुणवत्ता की जांच करना वांछनीय है: "प्रत्येक मॉड्यूल क्या कार्य करता है?", "मॉड्यूल का परीक्षण करना कितना आसान है?", "क्या मॉड्यूल का उपयोग स्वयं करना संभव है?" या किसी अन्य वातावरण में?" दूसरों को प्रभावित करते हैं?"

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

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

यह कहा जा सकता है कि decoupling के लिए तकनीकें मुख्य "वास्तुकार के टूलकिट" का गठन करती हैं। केवल यह समझना आवश्यक है कि हम सभी उप-प्रणालियों के बारे में बात कर रहे हैं और पदानुक्रम के सभी स्तरों पर कनेक्शन को कमजोर करना आवश्यक है , न केवल कक्षाओं के बीच, बल्कि प्रत्येक पदानुक्रमित स्तर पर मॉड्यूल के बीच भी।