सॉफ्टवेयर मॉड्यूल के बीच कपलिंग को कैसे ढीला करें

8.1 अपघटन ही सब कुछ है

स्पष्टता के लिए, एक अच्छे लेख "ऑब्जेक्ट-ओरिएंटेड सिस्टम्स का डिकूप्लिंग" से एक तस्वीर, जिसमें मुख्य बिंदुओं पर चर्चा की जाएगी।

क्या आपको अभी भी लगता है कि एप्लिकेशन आर्किटेक्चर डिजाइन करना आसान है?

8.2 इंटरफेस, कार्यान्वयन छिपाना

सिस्टम के युग्मन को कम करने के लिए मुख्य सिद्धांत OOP के सिद्धांत और उनके पीछे एनकैप्सुलेशन + अमूर्त + बहुरूपता के सिद्धांत हैं।

इस कर:

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

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

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

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

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

इंटरफेस और बहुरूपता के लिए धन्यवाद , यह पहले से ही लिखे गए (ओपन-क्लोज्ड प्रिंसिपल) को बदले बिना कोड को संशोधित करने और विस्तारित करने की क्षमता है।

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

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

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

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

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

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

यह सिद्धांत निम्नानुसार तैयार किया गया है: "ग्राहकों को उन तरीकों पर निर्भर नहीं होना चाहिए (विधियों से अवगत रहें) जिनका वे उपयोग नहीं करते हैं" या "कई विशिष्ट इंटरफेस एक सार्वभौमिक से बेहतर हैं"।

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

8.3 मुखौटा: मॉड्यूल इंटरफ़ेस

यहां एक अनुभवी प्रोग्रामर पूछेगा: यदि डिज़ाइन उन वस्तुओं के स्तर पर नहीं है जो स्वयं संबंधित इंटरफेस को लागू करते हैं, लेकिन मॉड्यूल के स्तर पर, तो मॉड्यूल इंटरफ़ेस का कार्यान्वयन क्या है?

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

एक मुखौटा एक इंटरफ़ेस ऑब्जेक्ट है जो एक निश्चित सबसिस्टम के साथ काम करने के लिए संचालन का एक उच्च-स्तरीय सेट जमा करता है, इसकी आंतरिक संरचना और इसके पीछे की वास्तविक जटिलता को छुपाता है । सबसिस्टम कार्यान्वयन में परिवर्तन के खिलाफ सुरक्षा प्रदान करता है। एकल प्रवेश बिंदु के रूप में कार्य करता है - "आप मुखौटा को लात मारते हैं, और वह जानता है कि इस सबसिस्टम में किसे किक करने की आवश्यकता है ताकि वह प्राप्त कर सके।"

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

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

नोट : हालांकि अधिकांश प्रोग्रामर कक्षाओं (ऑब्जेक्ट्स) को डिजाइन करते समय इंटरफेस के महत्व को समझते हैं, ऐसा लगता है कि कई मॉड्यूल स्तर पर इंटरफेस का उपयोग करने का विचार भी खोजते हैं।