मेसेजिंगसह थेट अवलंबित्व बदलणे
काहीवेळा मॉड्यूलला फक्त इतरांना सूचित करणे आवश्यक असते की त्यात काही घटना/बदल झाले आहेत आणि नंतर या माहितीचे काय होते हे महत्त्वाचे नाही.
या प्रकरणात, मॉड्यूल्सना "एकमेकांबद्दल जाणून घेण्याची" अजिबात आवश्यकता नाही, म्हणजे थेट दुवे असतात आणि थेट संवाद साधतात, परंतु केवळ संदेश (संदेश) किंवा कार्यक्रम (इव्हेंट) ची देवाणघेवाण करणे पुरेसे आहे.
कधीकधी असे दिसते की संदेशवहनाद्वारे मॉड्यूल संप्रेषण थेट अवलंबित्वापेक्षा खूपच कमकुवत आहे. खरंच, पद्धती कॉल केल्या जात नसल्यामुळे, वर्गांबद्दल कोणतीही माहिती नाही. पण हे एक भ्रमापेक्षा अधिक काही नाही.
पद्धतीच्या नावांऐवजी, लॉजिक संदेश प्रकार, त्यांचे पॅरामीटर्स आणि प्रसारित डेटाशी जोडले जाऊ लागते. अशा मॉड्यूल्सची कनेक्टिव्हिटी smeared आहे.
हे असे असायचे: आम्ही पद्धती म्हणतो - कनेक्टिव्हिटी आहे, आम्ही पद्धती कॉल करत नाही - कनेक्टिव्हिटी नाही. आता कल्पना करा की मॉड्यूल A त्याच्या संदेशांमध्ये थोडा वेगळा डेटा पाठवू लागला. आणि त्याच वेळी, या संदेशांवर अवलंबून असलेले सर्व मॉड्यूल योग्यरित्या कार्य करणार नाहीत.
समजा, पूर्वी, नवीन वापरकर्ता जोडताना, अधिकृतता मॉड्यूलने USER_ADDED संदेश पाठवला होता आणि अद्यतनानंतर, नोंदणी करण्याचा प्रयत्न करत असताना हा संदेश पाठवण्यास सुरुवात केली आणि याव्यतिरिक्त यशस्वी नोंदणी किंवा पॅरामीटर्समध्ये नाही हे सूचित केले.
त्यामुळे संदेश यंत्रणा अतिशय सक्षमपणे राबविणे अत्यंत आवश्यक आहे. यासाठी विविध टेम्पलेट्स आहेत.
निरीक्षक. हे एक-ते-अनेक अवलंबनाच्या बाबतीत वापरले जाते, जेव्हा अनेक मॉड्यूल एकच्या स्थितीवर अवलंबून असतात - मुख्य. हे मेलिंग यंत्रणा वापरते, याचा अर्थ मुख्य मॉड्यूल त्याच्या सर्व सदस्यांना समान संदेश पाठवते आणि या माहितीमध्ये स्वारस्य असलेले मॉड्यूल "सदस्य" इंटरफेस लागू करतात आणि मेलिंग सूचीची सदस्यता घेतात.
हा दृष्टीकोन वापरकर्ता इंटरफेस असलेल्या सिस्टीममध्ये मोठ्या प्रमाणावर वापरला जातो, अनुप्रयोगाचा (मॉडेल) मुख्य भाग स्वतंत्र राहण्यास अनुमती देतो आणि त्याच्याशी संबंधित इंटरफेसला सूचित करतो की काहीतरी बदलले आहे आणि अद्यतनित करणे आवश्यक आहे.
येथे संदेश स्वरूप ऑपरेटिंग सिस्टम स्तरावर प्रमाणित आहे, ज्याच्या विकासकांनी मागास अनुकूलता आणि चांगल्या दस्तऐवजीकरणाची काळजी घेणे आवश्यक आहे.
संदेशांच्या वितरणाद्वारे परस्परसंवादाच्या संस्थेमध्ये अतिरिक्त "बोनस" असतो - "प्रकाशित" (म्हणजे पाठवलेले) संदेशांसाठी "सदस्यांचे" पर्यायी अस्तित्व. यासारखी सु-डिझाइन केलेली प्रणाली कधीही मॉड्यूल जोडण्यासाठी/काढण्याची परवानगी देते.
मेसेजिंग बस
तुम्ही संदेशांची देवाणघेवाण आयोजित करू शकता आणि यासाठी मध्यस्थ नमुना वेगळ्या प्रकारे वापरू शकता .
जेव्हा मॉड्यूल्समध्ये अनेक-ते-अनेक अवलंबित्व असते तेव्हा ते वापरले जाते. मध्यस्थ मॉड्यूल्समधील संप्रेषणामध्ये मध्यस्थ म्हणून कार्य करतो, संप्रेषण केंद्र म्हणून कार्य करतो आणि मॉड्यूल्सची एकमेकांना स्पष्टपणे संदर्भित करण्याची आवश्यकता दूर करतो.
परिणामी, मॉड्यूल्सचा एकमेकांशी परस्परसंवाद ("सर्वांसह") केवळ मध्यस्थासह ("सर्वांसह एक") मॉड्यूलच्या परस्परसंवादाद्वारे बदलला जातो. मध्यस्थ बहुविध मॉड्यूल्समधील परस्परसंवाद एन्कॅप्स्युलेट करतो असे म्हटले जाते.
हे तथाकथित स्मार्ट मध्यस्थ आहे . तेथेच विकासक बहुतेकदा त्यांचे क्रॅच जोडण्यास सुरवात करतात, जे विशिष्ट संदेश प्राप्त करून चालू / बंद करून वैयक्तिक मॉड्यूलच्या वर्तनावर प्रभाव पाडतात.
एक सामान्य वास्तविक जीवन उदाहरण म्हणजे विमानतळ वाहतूक नियंत्रण. विमानातील सर्व संदेश थेट विमानादरम्यान पाठवण्याऐवजी नियंत्रकाच्या नियंत्रण टॉवरवर जातात. आणि नियंत्रक आधीच निर्णय घेतो की कोणती विमाने टेक ऑफ किंवा लँड करू शकतात आणि त्या बदल्यात, विमानांना संदेश पाठवतात.
महत्वाचे! मॉड्यूल्स एकमेकांना केवळ साधे संदेशच पाठवू शकत नाहीत तर ऑब्जेक्ट्स देखील पाठवू शकतात. अशा परस्परसंवादाचे वर्णन कमांड टेम्पलेटद्वारे केले जाते . तळ ओळ एक विशिष्ट कृती करण्याची विनंती विभक्त ऑब्जेक्ट म्हणून अंतर्भूत करण्याची आहे.
खरं तर, या ऑब्जेक्टमध्ये एकच execute() पद्धत आहे, जी नंतर तुम्हाला ही क्रिया पॅरामीटर म्हणून कार्यान्वित करण्यासाठी इतर मॉड्यूल्समध्ये पास करण्याची परवानगी देते आणि सामान्यत: कमांड ऑब्जेक्टसह कोणतीही ऑपरेशन्स करू शकते जी सामान्य ऑब्जेक्टवर करता येते.
डीमीटरचा कायदा
डीमीटरचा कायदा अंतर्निहित अवलंबनांचा वापर करण्यास मनाई करतो: "ऑब्जेक्ट A ला ऑब्जेक्ट B मध्ये प्रवेश असल्यास आणि ऑब्जेक्ट B ला ऑब्जेक्ट C मध्ये प्रवेश असल्यास ऑब्जेक्ट A थेट ऑब्जेक्ट C मध्ये प्रवेश करू शकत नाही."
याचा अर्थ असा की कोडमधील सर्व अवलंबित्व "स्पष्ट" असणे आवश्यक आहे - वर्ग / मॉड्यूल त्यांच्या कामात फक्त "त्यांचे अवलंबन" वापरू शकतात आणि त्यांच्याद्वारे इतरांपर्यंत चढू नयेत. एक उत्तम उदाहरण म्हणजे त्रिस्तरीय आर्किटेक्चर. इंटरफेस लेयरने लॉजिक लेयरसह कार्य केले पाहिजे, परंतु डेटाबेस लेयरशी थेट संवाद साधू नये.
थोडक्यात, हे तत्त्व देखील अशा प्रकारे तयार केले गेले आहे: "केवळ जवळच्या मित्रांशी संवाद साधा, मित्रांच्या मित्रांशी नाही." हे कोडची कमी सुसंगतता, तसेच त्याच्या डिझाइनची अधिक दृश्यमानता आणि पारदर्शकता प्राप्त करते.
डीमीटरचा कायदा आधीच नमूद केलेले "किमान ज्ञानाचे तत्त्व" लागू करतो, जो सैल कपलिंगचा आधार आहे आणि त्यात वस्तु/मॉड्युलला इतर ऑब्जेक्ट्स/मॉड्युलची रचना आणि गुणधर्मांबद्दल शक्य तितके कमी तपशील माहित असले पाहिजेत. सर्वसाधारणपणे काहीही, त्याच्या स्वतःच्या घटकांसह .
आयुष्यातील एक साधर्म्य: जर तुम्हाला कुत्र्याने पळायचे असेल तर, त्याच्या पंजेला आज्ञा देणे मूर्खपणाचे आहे, कुत्र्याला आज्ञा देणे चांगले आहे आणि ती स्वतः तिच्या पंजे हाताळेल.
वारसा ऐवजी रचना
हा खूप मोठा आणि मनोरंजक विषय आहे आणि तो किमान स्वतंत्र व्याख्यानास पात्र आहे. एकमत होईपर्यंत इंटरनेटवर या विषयावर बर्‍याच प्रती खंडित केल्या गेल्या - आम्ही कमीतकमी, रचना - जास्तीत जास्त वारसा वापरतो.
मुद्दा असा आहे की वारसा प्रत्यक्षात वर्गांमधील सर्वात मजबूत कनेक्शन प्रदान करते, म्हणून ते टाळले पाहिजे. हा विषय हर्ब सटर यांच्या लेखात " प्रिफर कंपोझिशन ओव्हर इनहेरिटन्स " मध्ये चांगलाच मांडला आहे.
जेव्हा तुम्ही डिझाईन पॅटर्न शिकण्यास सुरुवात कराल, तेव्हा तुम्हाला अनेक पॅटर्न आढळतील जे एखाद्या वस्तूच्या निर्मितीवर किंवा त्याच्या अंतर्गत संरचनेवर नियंत्रण ठेवतात. तसे, मी या संदर्भात डेलीगेट / डेलिगेट पॅटर्न आणि गेममधून आलेल्या घटक पॅटर्नकडे लक्ष देण्याचा सल्ला देऊ शकतो .
आम्ही थोड्या वेळाने नमुन्यांबद्दल अधिक बोलू.
GO TO FULL VERSION