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

8.1 विघटन हे सर्वकाही आहे

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

तुम्हाला अजूनही वाटते की अॅप्लिकेशन आर्किटेक्चर डिझाइन करणे सोपे आहे?

8.2 इंटरफेस, अंमलबजावणी लपवणे

प्रणालीचे कपलिंग कमी करण्यासाठी मुख्य तत्त्वे म्हणजे OOP ची तत्त्वे आणि त्यामागील Encapsulation + Abstraction + Polymorphism चे तत्त्व.

म्हणूनच:

• मॉड्यूल एकमेकांसाठी "ब्लॅक बॉक्स" असावेत (एनकॅप्सुलेशन) . याचा अर्थ एका मॉड्यूलने दुसर्‍या मॉड्यूलमध्ये "चढून" जाऊ नये आणि त्याच्या अंतर्गत संरचनेबद्दल काहीही माहित नसावे. एका सबसिस्टममधील ऑब्जेक्ट्सने दुसऱ्या सबसिस्टममधील ऑब्जेक्ट्समध्ये थेट प्रवेश करू नये.
• मॉड्यूल्स/उपप्रणालींनी एकमेकांशी फक्त इंटरफेसद्वारे संवाद साधला पाहिजे (म्हणजे, अॅब्स्ट्रॅक्शन जे अंमलबजावणी तपशीलांवर अवलंबून नाहीत). त्यानुसार, प्रत्येक मॉड्यूलमध्ये इतर मॉड्यूल्सशी संवाद साधण्यासाठी एक सु-परिभाषित इंटरफेस किंवा इंटरफेस असणे आवश्यक आहे.

"ब्लॅक बॉक्स" (एनकॅप्सुलेशन) चे तत्त्व आम्हाला प्रत्येक उपप्रणालीची रचना इतर उपप्रणालींपेक्षा स्वतंत्रपणे विचारात घेण्यास अनुमती देते. मॉड्यूल, जे "ब्लॅक बॉक्स" आहे, तुलनेने मुक्तपणे बदलले जाऊ शकते. समस्या फक्त वेगवेगळ्या मॉड्यूल्सच्या जंक्शनवर (किंवा मॉड्यूल आणि वातावरण) उद्भवू शकतात.

आणि या परस्परसंवादाचे वर्णन सर्वात सामान्य (अमूर्त) स्वरूपात करणे आवश्यक आहे, म्हणजेच इंटरफेसच्या स्वरूपात. या प्रकरणात, कोड इंटरफेस कराराशी सुसंगत असलेल्या कोणत्याही अंमलबजावणीसह समान कार्य करेल. एका युनिफाइड इंटरफेसद्वारे विविध अंमलबजावणी (मॉड्यूल किंवा ऑब्जेक्ट्स) सह कार्य करण्याची ही क्षमता आहे ज्याला पॉलिमॉर्फिझम म्हणतात.

म्हणूनच सर्व्हलेट हा एक इंटरफेस आहे : वेब कंटेनरला सर्व्हलेटबद्दल काहीही माहिती नसते, त्यासाठी हे काही ऑब्जेक्ट्स आहेत जे सर्व्हलेट इंटरफेस लागू करतात आणि तेच. सर्व्हलेट्सना कंटेनरच्या संरचनेबद्दल थोडी माहिती असते. सर्व्हलेट इंटरफेस हा करार, तो मानक, जावा वेब ऍप्लिकेशन्सना जगावर कब्जा करण्यासाठी आवश्यक असलेला किमान परस्परसंवाद आहे.

पॉलिमॉर्फिझम हे पद्धतींचे अजिबात ओव्हरराइडिंग नाही, जसे की कधीकधी चुकून विश्वास ठेवला जातो, परंतु सर्व प्रथम, समान इंटरफेस किंवा "एक इंटरफेस, अनेक अंमलबजावणी" असलेल्या मॉड्यूल्स / ऑब्जेक्ट्सची अदलाबदली. पॉलिमॉर्फिझम अंमलात आणण्यासाठी, वारसा यंत्रणा अजिबात आवश्यक नाही. हे समजून घेणे महत्त्वाचे आहे कारण जेव्हा शक्य असेल तेव्हा सर्वसाधारणपणे वारसा टाळला पाहिजे .

इंटरफेस आणि पॉलिमॉर्फिझमबद्दल धन्यवाद , आधीच लिहिलेले (ओपन-क्लोज्ड प्रिन्सिपल) न बदलता कोड सुधारण्याची आणि विस्तारित करण्याची क्षमता अचूकपणे प्राप्त झाली आहे.

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

हे LEGO कन्स्ट्रक्टर प्रमाणेच आहे - इंटरफेस परस्परसंवादाचे प्रमाणिकरण करतो आणि एक प्रकारचे कनेक्टर म्हणून काम करतो जेथे योग्य कनेक्टर असलेले कोणतेही मॉड्यूल कनेक्ट केले जाऊ शकते.

डिझायनरची लवचिकता या वस्तुस्थितीद्वारे सुनिश्चित केली जाते की आम्ही एकाच कनेक्टरसह (समान इंटरफेससह) फक्त एक मॉड्यूल किंवा भाग दुसर्‍यासह बदलू शकतो, तसेच आम्हाला हवे तितके नवीन भाग जोडू शकतो (त्याच वेळी, विद्यमान भाग कोणत्याही प्रकारे बदललेले किंवा बदललेले नाहीत).

इंटरफेस आपल्याला प्रत्येक उपप्रणालीचा संपूर्ण विचार करून आणि त्याच्या अंतर्गत संरचनेकडे दुर्लक्ष करून, एक सोपी प्रणाली तयार करण्याची परवानगी देतात. ते मॉड्यूलला परस्परसंवाद करण्याची परवानगी देतात आणि त्याच वेळी एकमेकांच्या अंतर्गत संरचनेबद्दल काहीही माहिती नसतात, ज्यामुळे कमीतकमी ज्ञानाचे तत्त्व पूर्णपणे लागू होते, जे सैल कपलिंगचा आधार आहे.

इंटरफेस जितके अधिक सामान्य/अमूर्त परिभाषित केले जातील आणि ते परस्परसंवादावर जितके कमी निर्बंध लादतील तितकी प्रणाली अधिक लवचिक असेल. येथून, सॉलिडचे आणखी एक तत्त्व प्रत्यक्षात पाळले जाते - इंटरफेस सेग्रिगेशन तत्त्व , जे "जाड इंटरफेस" ला विरोध करते.

तो म्हणतो की मोठे, अवजड इंटरफेस लहान, अधिक विशिष्ट मध्ये विभागले जावे, जेणेकरून लहान इंटरफेसच्या क्लायंटला (अवलंबून मॉड्यूल्स) फक्त त्यांना काम करण्यासाठी आवश्यक असलेल्या पद्धतींबद्दल माहिती असेल.

हे तत्त्व खालीलप्रमाणे तयार केले आहे: "ग्राहकाने वापरत नसलेल्या पद्धतींवर अवलंबून राहू नये (पद्धतींबद्दल जागरूक असावे) किंवा "अनेक विशेष इंटरफेस एका सार्वत्रिक इंटरफेसपेक्षा चांगले आहेत".

असे दिसून आले की कमकुवत कनेक्टिव्हिटी प्रदान केली जाते जेव्हा मॉड्यूल्सची परस्परसंवाद आणि अवलंबित्व केवळ इंटरफेसच्या मदतीने वर्णन केले जाते, म्हणजे, अॅब्स्ट्रॅक्शन्स, त्यांच्या अंतर्गत रचना आणि संरचनेबद्दल ज्ञान न वापरता. आणि खरं तर, अशा प्रकारे एन्कॅप्सुलेशन लागू केले जाते. शिवाय, आमच्याकडे विविध अंमलबजावणी जोडून आणि वापरून प्रणालीचे वर्तन विस्तारित / बदलण्याची क्षमता आहे, म्हणजे, बहुरूपतेमुळे. होय, आम्ही पुन्हा OOP वर आलो - एन्कॅप्सुलेशन, अॅब्स्ट्रॅक्शन, पॉलीमॉर्फिझम.

8.3 दर्शनी भाग: मॉड्यूल इंटरफेस

येथे एक अनुभवी प्रोग्रामर विचारेल: जर डिझाइन ऑब्जेक्ट्सच्या स्तरावर नसेल जे स्वतः संबंधित इंटरफेस लागू करतात, परंतु मॉड्यूल्सच्या स्तरावर असतील, तर मॉड्यूल इंटरफेसची अंमलबजावणी काय आहे?

उत्तरः डिझाइन पॅटर्नच्या भाषेत बोलणे, नंतर मॉड्यूल इंटरफेसच्या अंमलबजावणीसाठी एक विशेष ऑब्जेक्ट जबाबदार असू शकतो - दर्शनी . गेटवे प्रत्यय (उदाहरणार्थ, MobileApiGateway) असलेल्या ऑब्जेक्टवर तुम्ही मेथड कॉल करत असल्यास, बहुधा ते दर्शनी भाग असेल.

दर्शनी भाग हा एक इंटरफेस ऑब्जेक्ट आहे जो विशिष्ट उपप्रणालीसह कार्य करण्यासाठी उच्च-स्तरीय ऑपरेशन्स जमा करतो, त्याची अंतर्गत रचना आणि त्यामागील खरी जटिलता लपवतो . उपप्रणाली अंमलबजावणीतील बदलांपासून संरक्षण प्रदान करते. एकल एंट्री पॉईंट म्हणून काम करते - "तुम्ही दर्शनी भागावर लाथ मारता, आणि त्याला माहित आहे की या उपप्रणालीमध्ये कोणाला लाथ मारण्याची गरज आहे ते मिळवण्यासाठी."

तुम्‍हाला नुकतेच एका सर्वात महत्‍त्‍वाच्‍या डिझाईन पॅटर्नशी ओळख करून दिली गेली आहे जी तुम्‍हाला मॉडयुल्‍स डिझाईन करताना इंटरफेसच्‍या संकल्‍पना वापरण्‍याची परवानगी देते आणि त्‍यायोगे त्‍यांना डीकपल करता येते - "फेकेड".

याव्यतिरिक्त, "फेकेड" सामान्य वस्तूंप्रमाणेच मॉड्यूलसह ​​कार्य करणे शक्य करते आणि मॉड्यूल डिझाइन करताना वर्गांच्या डिझाइनमध्ये वापरल्या जाणार्‍या सर्व उपयुक्त तत्त्वे आणि तंत्रे लागू करतात.

टीप : वर्ग (ऑब्जेक्ट) डिझाइन करताना बहुतेक प्रोग्रामर इंटरफेसचे महत्त्व समजत असले तरी, असे दिसते की अनेकांना मॉड्यूल स्तरावर इंटरफेस वापरण्याची कल्पना देखील आली आहे.